在前面的几篇文章中，笔者依次点明ERP的三处“软肋”，即取消会计的库存账、不能全过程计算产品成本和不能编制现金流量表。计算机应用于企业管理，习惯上叫管理信息系统（MIS），ERP只是MIS的时尚别名，是20世纪90年代才提出来的新概念。而会计信息系统（AIS）本来就属于管理信息系统（MIS），公认是后者的有机组成部分。从会计领域下手评说，不但没有偏题，还便于读者基于自已的专业背景，判断这些批评是否有道理。本文打算从后台会计转向前台业务，围绕会计所监控的“供产销三环节”，考察ERP在内部物流管理方面的实际业绩，分析其之所以失败的设计根源。
模块成功≠ERP成功
我们顺着供产销主流程来观察实物流动，会感到它是非常直观的直线过程，就如图1中的粗黑线所表示的，从供应商发送原材料开始，进入原材料库，然后投入生产制造，完工后进入产成品库，最后送到顾客手中而结束。根据这样的表面现象，如果让“铁路警察各管一段”，用采购模块处理供应商与原材料采购的关系，用生产管理模块来管理从原材料投入到产成品交库的内部过程，用销售模块处理顾客和产成品发送的关系，似乎也有道理，而且以模块套装式构建整体的ERP，是全世界一致的套路，好像所有人都同意，ERP天生就该这么切块的。甚至可以说，ERP领域最为显眼的关键词，便是“模块化”。不知道从什么时候起，会计软件也好，ERP软件也好，都成了买卖“模块”的交易。供应商迫不及待地演示模块，告诉我们可以选择买一个模块、两个模块……要多少，只管放心往上堆就是了，模块越多的供应商越有说服力。用户受这种“教化”的结果，看到模块什么功能都有，高兴得很，除了只会问“你这软件有多少模块？”也就不知道还要了解什么了。
但是，模块是用来处理数据的，数据不能只“窝”在模块里流动，它要在模块间畅通无阻地来回流转！豆腐切开后不能无缝粘结，那么，模块切开后，总有个重组装问题，在模块接合部上，怎么确保数据流的衔接与一致？
这是ERP设计理念是否成立的根本性问题。我们从会计总账模块和库存模块之间的脱节，已可看到模块化设计的毛病。姑且不说库存明细账是“别人”的，即使ERP只让财务部自己用，也会有麻烦，那就是：库存模块有金额和数量双重核算，处理业务后，能向总账模块传送只有金额的记账凭证；总账模块只有粗略的金额核算，完成与库存有关的账务处理后，却不能向库存模块传送既有金额又有数量的数据，分摊到品种上，以保持双方一致。这就和“单向阀”一样，导致两个模块的数据脱节。其实，会计本来是从上到下浑然一体的，从总账到最底级的明细账一气呵成，把明细账加起来就是总账，永远也不会出问题。硬要切成总账和明细账模块，再来设法调平，岂不是舍近求远？
在物流调度上，更加回避不了的问题是：当试图用“大卸八块”的模块来处理畅通无阻的数据流时，必然碰到“模块为王”还是“数据为王”的问题。ERP显然是以模块为中心的，供应商对于模块功能描述得很细，但在模块与模块之间的接合部上，数据如何相互沟通，则完全没有人提起。
对于软件系统而言，唯一的评价标准就是用户的需求。那么用户要的是什么？不是模块，而是数据，处于不同职能上的用户是依靠数据工作的！首先要了解其所处理业务的当前状况，例如销售部要知道当前有多少可供销售的商品（这也许是仓库管理员等部门的操作结果）；采购部门要知道有多少未完成的销售订单，有多少可供销售的商品，该采购多少（这又是销售部门和仓库管理员等部门的操作结果）……其次，所有部门在软件上所做的操作，会立即改变后续工作所得到的信息，例如销售票据一旦开出，接着要开具下一张时，观察到的可供销售的商品数已减少了，财务部门知道要准备收款，仓库管理员知道该出货了，储运车队开始调度车辆……数据在各职能部门间畅通无阻，动态地交互作用，这才是评价ERP系统是否成功的终极标准。在许多案例中，套装式的ERP软件只用上一两个模块（如销售模块）便宣称ERP成功上线。可是，那和传统的信息孤岛软件又有什么区别呢？充其量也只是一个模块的成功，而绝不是ERP的成功。
为了找到答案，笔者曾遍翻某世界最知名的ERP厂商出版的十几册英文原版书，发现书中对每个模块的介绍都详尽无遗，而对于ERP是否成功的真正标志，即模块与模块之间如何沟通数据、如何使之交互作用、整体联动起来，几乎是不著一字，只看到“填表”（fill tables）一词还算与此有关，具体如何做，却又语焉不详。这只有两种可能，一是设计者自己也不知道；二是事关软件的超级商业机密，因此绝口不提。可是，该公司自己又不在现场干活，而是通过咨询顾问进行推广的，不交代清楚模块之间数据如何对流，让人怎么装配设置？所以，最可能的答案应是“设计者自己也不知道”。
案例演示
作战时，友军的结合部往往是最薄弱的环节，软件模块也是如此。所以，笔者就“哪不开偏提哪壶”，通过一个虚拟的商品流通企业案例，重点揭露模块结合部上的问题。
我们假设这个企业只经营一种商品，买进来以后就卖出去，完全按销售订单来组织供应。采用“就地收购”和“订单购进”两种供应方式，“就地收购”的过程是由供应商送上门来，暂放仓库，如果质量检验后符合要求，就承付货款成交，否则退还供应商自行拉回；“订单购进”则是一般的商业采购模式。为了便于统一管理，在完成各种有关物流的业务处理时，也将该业务登记在表1中，对表中的有关栏目说明如下：
业务说明：表现各种不同的业务类型。
对应项目：用于登记与该业务有关的机构或人员，如销售合同必有顾客，收货待验必有供应商，没有对应项时不必填写。
库存总数：仓库管理员所实际负责保管的存货。
自有数：在库存总数中，所有权属于会计主体的那一部分存货（会计后台监控的对象）。
代管：在库存总数中，属于为别人代管的那一部分存货，如供应商送来，尚未通过验收的存货，或顾客已领取，但尚未能拉走的存货等。
可用数：在自有数中，尚未有确定用途的那一部分存货，本栏合计数即“可用而未用数”。
已用数：在自有数中，已有确定用途的那一部分存货，本栏合计数即“已用而未提领数”。
未完销售：表现销售订单的签订和执行情况，本栏合计数即“已签订而未完成的销售数”。
未完采购；表现采购订单的签订和执行情况，本栏合计数即“已签订而未到货的采购数”。
在“业务说明”栏中，各类业务处理后，在登记表1时，该业务数据要满足的约束条件如下。
销售合同：签下销售合同的业务，因还未执行，对“东海超市”的“未完销售”做加法。
收货待验：就地收购的商品，茗香农庄送来，因还未验收，对“库存总数”和“代管数”栏做加法。要满足的约束条件：本次收货数≤（“未完销售”当前合计 – “可用数”当前合计 – “未完采购”当前合计）。
承付通知：对就地收购的“茗香农庄”代管商品，验收无异议后，通知财务付款。虽然财务付款也许还需时日，但已可认为是自己的商品了，所以对“代管数”做减法，对“自有数”和“可用数”做加法。要满足的约束条件：承付商品数≤“茗香农庄”的“代管”当前合计数。
采购订单：对东风茶厂发出采购订单，对“未完采购”做加法。要满足的约束条件：本次采购数≤（“未完销售”当前合计 –“可用数”当前合计 – “未完采购”当前合计）。
采购进库：对东风茶厂发出的采购订单到货，对“东风茶厂”的“未完采购”做减法，对“库存总数”、“自有数”和“可用数”做加法。要满足的约束条件：本次进库数≤“东风茶厂”的“未完采购”当前合计数。
销售开单：组织供货完成，对东海超市开出销售单，对“可用数”和“未完销售”栏做减法，对“已用数”做加法。要满足的约束条件：本次开单数≤“可用数”当前合计数，且本次开单数≤“东海超市”的“未完销售”当前合计数。
销售出货：东海超市提货，仓库管理员登记出货业务，对“库存总数”、“自有数”和“已用数”栏做减法。要满足的约束条件：本次出货数≤“东海超市”的“已用数”。
从该案例可见，所有部门既是数据需求方，也是数据提供方，某一职能部门的工作均要受到其他部门前期工作结果的约束，而其操作结果也反过来对其他部门产生约束作用，他们相互的信息依赖性很强，数据要在有关职能部门间不定向地流动，想切也切不开。读者也许不相信，这么一个简单得不能再简单的表格，它所表达的，才是用户对ERP物流管理的真正数据要求。如果各部门都在一起，没有通信问题，也忽略手工处理速度低的问题，为每种物料设一张表，按以上规则填写这个表，是不是已经把物流管起来了，存货还压到了最低？内部物流管理是ERP的核心，而其成功运作的唯一标志，就是涉及物流的各部门“整体联动”地工作，实现最佳调控。达不到这一要求的ERP，都是失败的。
可以说，ERP极高的失败率，其实就源于“信息孤岛”式的模块设计，特别是在物流管理领域，设计者将手段（模块）置于目标（数据）之上，任意切块，阻断了数据在各部门间的顺畅流动。
