浅析ORACLE ERP系统维护方法

 

浅析ORACLE ERP系统维护方法

 

 

笔者曾从事ORACLE ERP系统客户服务工作多年，在ERP系统维护工作中，深深体会到：

ERP的系统维护工作看似平常，实则大有学问。

 

ORACLE ERP系统是一个大型集成的软件系统，是一个企业全面共享的信息数据库，主要

包括制造、分销、财务等多个模块，各个模块相互关联，数据共享。系统的维护工作包

括日常维护及突发事件处理，日常维护是对系统的运行情况做定期或者不定期的诊断、

评估，突发事件是对系统中发生的错误及异常情况进行诊断、处理。维护工作是一个综

合的业务处理，处理过程可能与操作有关，可能与系统本身相关，也可能两者兼而有

之。系统的维护考验维护人员的综合素质，他需要对ERP系统及对企业实际业务都要有

全面深入的了解，同时还需要一些技巧的处理。由于ERP系统的全面集成性，所谓牵一

发而动全身，一个小小的处理不当，可能引来后患无穷，因此系统的维护需要小心谨

慎，通盘考虑。

 

以下为本人在实际工作中的一些经验总结，结合一些具体的例子，分享给大家。

 

一、要有独立的判断能力，学会听懂用户的说话，但不要被用户误导。 

 

我们维护人员常说的一句话，永远不要相信用户，要相信自己的判断。

 

学会认真倾听用户的话，但不要被用户牵着鼻子走。用户的应用水平参差不齐，表达能

力也不尽相同，要明白他们意见背后究竟想要说明的是什么，特别是对那些有一定经验

的用户，更要认真分析他的反馈，由于他对系统的一些问题认识不足，有时还会误导你

的判断。

 

ERP系统的问题千变万化，有用户操作的问题，有系统的问题，特别是用户操作层面的

问题，更是千奇百怪，有权限的问题，有操作顺序的问题，有业务理解的问题，不一而

足。同样的问题症状，但不一定是同样的原因，也不一定适用同样的处理方法。

 

维护人员接到问题时，不要着急，首先要做的事，要明白用户是在哪个环节，哪个层面

上出错，一定要调查清楚（这一点在对于远程维护、电话维护中更加重要），然后对具

体问题进行具体分析。

 

比如有一次，某客户（企业内部系统维护人员）向我反映，应付模块中的税码全部不见

了，问我是不是从后台做了什么操作。当时一听到这话，我可是吓坏了，税码的设置只

有超级用户或者系统管理员才有权限，难道有人不小心，从后台删除了数据？又或者是

系统存在BUG？我首先询问，有没人进行后台操作，回答是无，接着急急忙忙进入系

统，查询之后，发现税码设置好好的，都还在。于是，我仔细地询问了客户，是什么情

况下发现税码找不到的，用户说，昨天还可录入税码的，今天就不行了，我继续追问，

问题具体出现到哪个操作过程中。客户说是在录入发票过程中，并说明了具体的发票

号。于是，我进入此发票的发票行进行查询，果然找不到税码，真是太奇怪了，设置是

正常的，为何就找不到呢？查看其他发票又是正常，看来要从发票本身去查找原因了，

我与其他发票认真比较分析之下，发现发票日期有问题，当前年份是2008年，用户却录

成了1008年，提前了1000年，而税码设置中，税码是从2000年生效的，当然找不到了。

我将发票年份修改为2008，问题就立马解决了。

 

这是一个看起来很简单的问题，但如果不仔细分析，听从用户的反应，在后台查找原

因，反而会越走越远，所以维护人员一定要有独立的判断能力。

 

二、追根溯源，寻找问题的最终节点。 

 

ERP系统是一个大型集成的系统工程，各个模块之间关联紧密，作为ERP系统的维护人

员，要具有综合的素质，对于系统、业务都要有全面的理解，从而能发现问题，追根溯

源，寻找问题的最终节点。

 

比如在财务模块维护中常见的问题，库存模块账务与总帐模块账务不符。在用户将这个

问题抛出来之后，我们应该如何着手，去进行诊断分析呢？

 

首先，我们需要理解以ORACLE系统库存账务传送到总账的全过程，以ORACLE 11I版本为

例，各个处理环节如下： 

1）库存事务处理； 

2）库存事务生成会计分录； 

3）库存会计分录传送至过总账； 

4）库存日记账在总账过账。

 

在各个环节可能出现的错误如下： 

 

1）库存事务处理有错误，系统不能创建会计分录； 

2）成本管理器出错，创建分录不完整； 

3）库存事务未正确传送到总帐； 

4）库存总账日记帐未过账，试算表不能体现科目余额。

 

有这么多可能出现的错误，那么从哪个点切入比较好呢？我的经验是，先假定前几个步

骤是正确的，从最后一步开始检查，步步反推，直至找到问题的根源，这样的处理过程

效率更高，同时又能无一遗漏地进行全面的检查。比如上述问题，我们首先假定是库存

日记账未过账引进的错误，先检查相关日记账状态，如是未过账，则过账则可，如不是

此问题，再向上追溯，查看库存是否传送到总账，库存事务是否生成了会计分录，如此

层层推进，直至找到问题的具体所在。

 

在对系统的全面理解的基础上，追根溯源，处理问题，是行之有效的解决方案。

 

三、大胆假设，小心求证，模拟错误的发生。 

 

在ERP系统的维护过程中，有时还需要一些想象，去模拟错误的发生场景。要知道，有

各种各样的用户，就有各种各样你意想不到的操作，系统运行中也有千奇百怪的错误。

有时候，系统出现的错误，让你不知所措，无从借鉴，根本无从着手，怎么办？这时，

不妨冷静下来，去假设一下，如果你是用户，你可能会如何操作？系统又可能会出现哪

些错误？

 

比如一次维护过程中，客户方发现了一次大问题，系统执行成品标准标准更新时，出现

异常的WIP 标准成本调整差异，发生的总额约1000多万。其症状也是让人莫明其妙： 

 

1）物料为当时已完工的但未关闭的任务上的装配件。 

2）物料更新前的标准成本与冻结成本一致，更新后系统新的冻结成本也未发生变化。

按照系统的原理，此时不应该出现成本更新差异。物料更新前的标准成本与冻结成本不

一致的，出现成本更新差异也不是正常更新前后的差额。 

3）任务上发生的更新差异，有相当于将成品装配件成本从零成本更新到现有成本时的

差异，有的将成品装配件成本从现有成本时更新到零成本的差异，也有数据为（旧成本

*2-新成本），金额为现有任务上数量*现有标准成本差异。 

4）成本更新只产生了任务上的WIP差异，未产生库存上的成本更新差异。

 

如此奇怪的问题，我从所未遇。在分析了各种可能出错的情况后，我认为，这种错误不

应是个别用户操作引发的，应是系统性的程序出错。经反复检查，多次测试后，终于发

现，错误是由一个客户化的成本更新程序引发的，程序运行时，在后台写表时，成本表

的某个字段被错误写入，从而引起数据紊乱。在对客户化程序进行修正之后，问题就自

然解决。

 

当然，大胆假设的难度有点大，这源于日常工作经验的点滴积累，正所谓厚积薄发。

 

四、从全局性出发，处理问题要干净利落，不留尾巴。 

 

系统的维护看似简单，实际上考验着对系统的全面认识。一个问题处理不当，可能会引

发其他的问题，问题处理得不完整，当时可能没什么反应，但可能在后续的时间内暴露

出其他的问题。ERP不是信息孤岛，各数据之间是相互集成，相互关联，所以处理问题

时，要通盘考虑，这个数据与各模块的关联，与各数据的影响，后续影响等，一定要将

问题处理得干净利落，不留尾巴。

 

我们处理一个问题，至少要考虑以下几点： 

 

1）问题发生的原因是什么？ 

2）问题如何解决？ 

3）相关的引发的问题如何解决？ 

4）如何从源头上避免问题再度发生。

 

下面经一个库存科目定义错误引发的账务错误为例，说明处理方案。

 

比如：库存科目定义出错，将资产类科目定义成了费用类科目，造成的后果：库存模块

产生了大量错误会计分录，并已传送到总账接口，子库科目设置也未更改。

 

对于这样的错误，我们分析如下： 

 

错误的原因在于子库科目设置错误，需要进行修改，引发的错误在于会计分录错误，也

要修改，同时由于设置的需要，在修改子库科目前必须将现有量清零。

 

基于此，处理方案如下： 

 

1）清理子库科目需要更改的子库名称； 

2）设置帐户别名，用于处理子库科目调整； 

3）子库存数据备份； 

4）对库存数据做清零； 

5）修改子库帐户设置； 

6）使用帐户别名将子库数量接收或发放回原子库； 

7）从后台更改已产生会计分录的科目代码； 

8）注意事项：处理过程中此子库不应进行其他操作，也不能做成本更新。

 

从以上处理过程中，我们意识到，处理问题要一定要完整，要考虑到方方面面的需求。

 

五、举一反三，建立维护问题库。 

 

在维护的过程中，我们会遇到形形色色的问题，在解决问题的同时，我们需要将其记录

下来，记录问题发生、解决方案，持之以恒，积少成多，建立问题库，并进行归类，汇

总分析，总结经验并寻找规律。这是一个知识积累、知识沉淀的过程，在这个过程中，

进行总结、归纳、提升。

 

这个作用是双面的，一方面是自身的总结提高，以后可快速解决问题；另一方面，也可

用来培训客户，提供参考。

 

知识积累有利于系统化分析问题，形成维护经验体系，从而全面提高企业的ERP系统应

用与维护水平。