MRP(物料需求计划)运算是MRP系统甚至ERP系统的核心环节，一般的ERP系统都宣称自己有MRP模块。然而我们却极少能看到有人撰文详细描述其运算原理、运算细节和各种不同情况的处理方法(比如本文所论述的产品升级的处理措施)，不管是从甲方的角度或者是乙方的角度，这样的文章都很少见。因此笔者猜想，实际上MRP运算在中国的企业信息化业界的实施率比较低，能够实施的企业很少，能够成功实施的企业就更少了。

        这一点笔者的亲身经历可以做佐证。今天6月份笔者参加e-works举办的管理信息化大会，最后圆桌讨论的环节，国内一家知名豆浆机生产厂商的参会人员介绍了自己企业的ERP实施经验(上的是Oracle)，据他们自己说，MRP上线了，并且指导采购，然后当笔者追问其MRP的运算原理时,得到的回答是:他们自己也不知道Oracle里面是如何运行的，只知道系统能跑出结果来。当然，潜台词就是：运算结果准确与否他们也无法确认。

        实际上，与充满人为因素和不确定因素的主生产计划(MPS)相比,MRP的人为不确定因素较少，而系统可以支持的数据条件比较多，是实现系统自动运算的理想模块，也是比较能够体现ERP精髓思想的模块。我认为，MPS主生产计划由于人为因素太多和各企业环境复杂条件不一，很难实现完全由系统运算，比较适宜采用半系统运算半人工干预的方式。而MRP物料需求，在企业各方面条件成熟(比如库存数据准确,BOM清晰准确)的条件下，是可以实现自动运算的，而运算结果可以用于直接指导采购。天津广讯目前就做到了这一点。当然了，具体需要处理的难题仍然很多，比如今天说的这个问题。

        首先来大概讲讲MRP系统运算的原理。首先，MRP的源头来自于销售订单和在制生产工单，其中销售订单的需求量首先要扣除已出库量，然后要扣除已根据自身下达的生产工单的“待生产量”。然后把销售订单和在制工单的需求量合并，依据BOM向下逐级展开，每一级展开都有一个运算的过程(因为要考虑到库存，在途等等)，最终展到原材料(以及采购的成品半成品)这一级。就可以直接交给采购员用于下采购订单了。

 
        但是原理简单，实际问题却远远没有这样简单，我面临的一个困扰就是：产品升级太频繁了，怎么半?

        天津广讯是一家电子厂，生产电子通讯设备，产品更新变化很快，为了避免造成混乱，每种产品、半成品、原材料的唯一标识，除了物料号以外，还要加上一个“版本”，也就是说物料号+版本号才是一种东西的唯一身份证，比如A03821_0c这种东西，A03821是物料主号，0c就是版本号，它前面有0、0a、0b等旧版本，后面还可能有0d或者1等新版本，每一种版本都在系统中视为完全不同的两种东西，比如A03821_0b和A03821_0c系统就视为两种东西，以避免交给客户的产品出现差错。

         这样问题就出现了，在MRP的各级运算中，系统是依据各个单据中的物料号+版本号作为唯一标识进行运算的，问题是，版本升级得太快了。很容易造成各单据之间物料版本不统一，以及生产实际和系统中的物料版本不统一。比如上面所提的A03821吧，下销售订单和生产工单的时候，版本还是0b,所以销售订单和生产工单上面的版本都是0b，可是没过几天，由于产品BOM改良，版本就升到0c了，而实际生产也是按照0c生产的，生产入库也是按照0c入库的(系统允许生产工单和生产入库的版本不一致)。然后MRP一运算，麻烦就出来了，系统把不同版本的物料视为两种物料，所以本来按道理生产出来的0c可以抵扣销售单和工单的需求量的，但是由于销售单和工单的版本还是0b,所以不能抵扣，最终的运算结果当然就不对了。采购员为此跟我大呼小叫呢^--^

         那怎么办呢，这个问题解决起来还真有点棘手，而且我觉得这个问题其实很可能是电子、电器、机械等行业的一个通病，或者说有普遍性的一个问题。具体如何解决呢，不好意思了，今儿先写到这儿，就留到下一篇文章中接着说吧^--^。