最近项目应用过程中遇到一个问题，在这里项总结一下，以下简称NDFS项目。
这个项目幺蛾子特别多，之前提出要在领料单里增加价格信息，叫加权平均价，下面是他们给出的需求原文：
加权平均价指的是同一物资编码的物资不同入库单价入库在仓库内的加权平均价。
例如：该物资只有一批或同一入库单价入库，出库单价=入库单价；
当该物资由不同单价入库时（同一物资在不同合同中单价不一致），出库单价=（入库单价1*数量1+入库单价2*数量2）/（数量1+数量2）；出库单价为库内该物资入库单价的加权平均值，该价格为浮动价格，当该物资有新的入库物资时，价格变化为（库内单价1*库内数量+新入库单价2*新入库数量）/（库内数量+新入库数量）
该算法的目的是保持入库金额和出库金额平衡，出库金额用于业主与施工单位结算。
不知道你们看懂了没有，反正我看着似懂非懂，业主给出的理由听上去很有道理，实际却是一个很天马行空的用户需求。
工程物料管理系统从广义上来说可以管理费用，例如采买、支付请款，但是不应该在出库阶段管理货值，因为出库管理在软件的系统架构上已经属于仓库管理范畴了，仓库管理最核心的业务是什么？应该是管理到货量、仓储盘存、丢失损坏、申请领料、编制领料单、审批领料单、执行发料、领料单销账，我们会发现这些操作都是围绕材料的量来工作的，没有人关心我要领取的这个材料值多少钱，除非他是准备偷去卖钱，大家都只关心我要领多少，能给我多少，领不领的完。
一个比较大型的信息化系统，一般来说会从公司层面进行规划，通过代表公司的开发团队或者项目组召开开发协调会确定最终的流程，形成会议纪要。但是业主的要求往往是圣旨，我们在与业主的交锋中一般都没有话语权，最后各方的压力告诉我还是要做这个功能，于是我们今天要讨论的问题来了，当公司整体的规划需求和项目实际应用中发生的需求产生冲突的时候该怎么办？这个问题在软件投入使用以后非常普遍，也是一个困扰所有我们这种类型单位信息化工作的问题，我说一下我的思路。
首先。
绝对不是业主或者业务部室要什么就开发什么，因为以我十年的工作经验，凡是没有经过正式会议讨论研究确定的需求，最后基本都是做了白做，做好也没人用，你不把邮件拿出来他都不承认是他提出要做的，换个人或者项目就要你重新做，要拒绝这种需求，哪怕是业主提出的，这些需求大多是拍脑袋想出来的，想出来的那一瞬间都只看到了非常片面的场景。
比如这个加权平均价的需求，说起来好简单啊，加个框框显示价格不就完了吗？这都做不出来？说起来简单，这个货值的计算有很多种情况你们考虑了吗？材料丢失了，价格怎么算？材料损坏了但是东西还在仓库里，价格怎么算？材料损坏了，东西也不在仓库里了，价格怎么算？厂家发错东西了，价格还要不要？材料借出去了，价格？材料还回来了，价格？材料不还了，价格？材料开出领料单，但是没有领，价格？领了一半过几天再来领，价格？领了一半后面的不要了，过几天又开个重复的领料单，怎么算价格？领多了退回，价格？领多了不退，价格？材料退库回来已经被喷砂找不到编码了，不知道规格型号，怎么算价格？
你提一个需求，我要思考几十种可能的场景，有一种没有想到就留下一个漏洞，我们以为工作量就是水面上那一点冰山，其实冰山有90%都在水下面。
第二
信息化工作的本质建立标准的工作流、数据流。我认为这是信息化工作最有价值的地方，但是如果每个项目都提出一个与其它项目不一样的流程或者数据结构，那么就破坏了信息化工作的一个基本目标：标准，我们可以制定一个有弹性的标准，把可能遇到的情况包括进来，但是这些情况要适用于所有的项目，而不能某个项目的需求超出标准的弹性范围。
早期的规划是基线，后续的开发都应该在基线的控制下和约束下进行，比如我们作为EPC总包单位，编制流程的时候会根据EPC的一般性原则来决定仓库管理的范围，EPC项目的仓库一般是由总包公司来管理，C如果归总包公司管，就不存在我们跟施工单位核算与材料有关的费用（除非是丢失、损坏、安装错误等施工单位造成的损失应该补偿我司等这类情况），只有仓库财务独立核算（包括所有材料的费用）的情况下计算进出的货值才有意义，我们在早期规划的时候不可能预见到会有一个业主提出这样的要求，而且这个需求也不符合我们关于EPC仓库管理部分的要求。如果十个项目有九个都不需要这个流程，那我们应该考虑把它从标准流程中拿掉。
修改已经确定好的流程或者数据结构从IT开发角度来说意味着要修改底层的数据库结构，特别是针对关系型数据库，这对于一个正在运行的生产环境而言存在的巨大的风险，修改表结构往往意味着关联的数据可能存在需要手工处理的内容，软件涉及到该数据表的操作功能可能需要修改，工作量是成几何倍的增长，对于一个人力紧张的开发团队而言，这是现实问题。
第三
有很多办法可以帮助项目实现业主的这类要求比如在线下处理而不是放在线上，规避掉线上流程或者数据结构对于这个问题的强制性要求。对于这类需要自动计算的需求，手工处理确实有一些难度。但是有些问题确实可以绕过，还是这个NDFS项目，今天又提出一个要求，在原来的领料单审批环节增加两个审批节点，除了原来的施工工程师审批以外，还要业主和材控工程师审批，这个要求我也拒绝了，因为这是一个冗余的功能，没有实际意义，你要业主审批，在界面上点一下批准，无非就是要证明这个事经过了业主的审核，把业主拉入到责任链条中来，如果是这样的话，直接让业主在纸质版的单据上签个字不就完事了吗。线上流程拖得越长，对于软件的使用越不利，流程长出错卡住的环节就会增多，不能为了信息化而信息化。
第四
我们缺少一个机构来评判业主或者项目提出的需求是否应该纳入到公司的整体规划中，成为标准流程或者数据结构的一部分，应该有一个类似信息化委员会，但是要比委员会更加轻量级的专家组，他们要能快速反应，确定流程是否具有通用性，有权利决定是否开发这个需求，或是确定如何在线下完成没有通用性的流程，同时引导所有的项目在软件应用过程中，按照公司的标准流程和数据结构来执行。