您当前的位置:首页 > 会计论文>会计电算化论文

模块化:豆腐切开以后

2015-07-08 10:42 来源:学术参考网 作者:未知

  在前面的几篇文章中,笔者依次点明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极高的失败率,其实就源于“信息孤岛”式的模块设计,特别是在物流管理领域,设计者将手段(模块)置于目标(数据)之上,任意切块,阻断了数据在各部门间的顺畅流动。

相关文章
学术参考网 · 手机版
https://m.lw881.com/