ORACLE ERP系统维护经验谈

笔者曾从事ORACLE ERP系统客户服务工作多年，在ERP系统维护工作中，深深体会到：ERP的系统维护工作看似平常，实则大有学问。

ORACLE ERP系统是一个大型集成的软件系统，是一个企业全面共享的信息数据库，主要包括制造、分销、财务等多个模块，各个模块相互关联，数据共享。系统的维护工作包括日常维护及突发事件处理，日常维护是对系统的运行情况做定期或者不定期的诊断、评估，突发事件是对系统中发生的错误及异常情况进行诊断、处理。

维护工作是一个综合的业务处理，处理过程可能与操作有关，可能与系统本身相关，也可能两者兼而有之。系统的维护考验维护人员的综合素质，他需要对ERP系统及对企业实际业务都要有全面深入的了解，同时还需要一些技巧的处理。由于ERP系统的全面集成性，所谓牵一发而动全身，一个小小的处理不当，可能引来后患无穷，因此系统的维护需要小心谨慎，通盘考虑。

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

ORACLE ERP系统维护经验谈：一、要有独立的判断能力，学会听懂用户的说话，但不要被用户误导。

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

学会认真倾听用户的话，但不要被用户牵着鼻子走。用户的应用水平参差不齐，表达能力也不尽相同，要明白他们意见背后究竟想要说明的是什么，特别是对那些有一定经验的用户，更要认真分析他的反馈，由于他对系统的一些问题认识不足，有时还会误导你的判断。

ERP系统的问题千变万化，有用户操作的问题，有系统的问题，特别是用户操作层面的问题，更是千奇百怪，有权限的问题，有操作顺序的问题，有业务理解的问题，不一而足。同样的问题症状，但不一定是同样的原因，也不一定适用同样的处理方法。

维护人员接到问题时，不要着急，首先要做的事，要明白用户是在哪个环节，哪个层面上出错，一定要调查清楚（这一点在对于远程维护、电话维护中更加重要），然后对具体问题进行具体分析。

比如有一次，某客户（企业内部系统维护人员）向我反映，应付模块中的税码全部不见了，问我是不是从后台做了什么操作。当时一听到这话，我可是吓坏了，税码的设置只有超级用户或者系统管理员才有权限，难道有人不小心，从后台删除了数据？又或者是系统存在BUG？我首先询问，有没人进行后台操作，回答是无，接着急急忙忙进入系统，查询之后，发现税码设置好好的，都还在。于是，我仔细地询问了客户，是什么情况下发现税码找不到的，用户说，昨天还可录入税码的，今天就不行了，我继续追问，问题具体出现到哪个操作过程中。

客户说是在录入发票过程中，并说明了具体的发票号。于是，我进入此发票的发票行进行查询，果然找不到税码，真是太奇怪了，设置是正常的，为何就找不到呢？查看其他发票又是正常，看来要从发票本身去查找原因了，我与其他发票认真比较分析之下，发现发票日期有问题，当前年份是2008年，用户却录成了1008年，提前了1000年，而税码设置中，税码是从2000年生效的，当然找不到了。我将发票年份修改为2008，问题就立马解决了。

这是一个看起来很简单的问题，但如果不仔细分析，听从用户的反应，在后台查找原因，反而会越走越远，所以维护人员一定要有独立的判断能力。

ORACLE ERP系统维护经验谈：二、追根溯源，寻找问题的最终节点。

ERP系统是一个大型集成的系统工程，各个模块之间关联紧密，作为ERP系统的维护人员，要具有综合的素质，对于系统、业务都要有全面的理解，从而能发现问题，追根溯源，寻找问题的最终节点。

比如在财务模块维护中常见的问题，库存模块账务与总帐模块账务不符。在用户将这个问题抛出来之后，我们应该如何着手，去进行诊断分析呢？

首先，我们需要理解以ORACLE系统库存账务传送到总账的全过程，以ORACLE 11I版本为例，各个处理环节如下：

1）库存事务处理；
2）库存事务生成会计分录；
3）库存会计分录传送至过总账；
4）库存日记账在总账过账。

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

1）库存事务处理有错误，系统不能创建会计分录；
2）成本管理器出错，创建分录不完整；
3）库存事务未正确传送到总帐；
4）库存总账日记帐未过账，试算表不能体现科目余额。

有这么多可能出现的错误，那么从哪个点切入比较好呢？我的经验是，先假定前几个步骤是正确的，从最后一步开始检查，步步反推，直至找到问题的根源，这样的处理过程效率更高，同时又能无一遗漏地进行全面的检查。比如上述问题，我们首先假定是库存日记账未过账引进的错误，先检查相关日记账状态，如是未过账，则过账则可，如不是此问题，再向上追溯，查看库存是否传送到总账，库存事务是否生成了会计分录，如此层层推进，直至找到问题的具体所在。

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

ORACLE ERP系统维护经验谈：三、大胆假设，小心求证，模拟错误的发生。

在ERP系统的维护过程中，有时还需要一些想象，去模拟错误的发生场景。要知道，有各种各样的用户，就有各种各样你意想不到的操作，系统运行中也有千奇百怪的错误。有时候，系统出现的错误，让你不知所措，无从借鉴，根本无从着手，怎么办？这时，不妨冷静下来，去假设一下，如果你是用户，你可能会如何操作？系统又可能会出现哪些错误？

比如一次维护过程中，客户方发现了一次大问题，系统执行成品标准标准更新时，出现异常的WIP 标准成本调整差异，发生的总额约1000多万。其症状也是让人莫明其妙：

1）物料为当时已完工的但未关闭的任务上的装配件。
2）物料更新前的标准成本与冻结成本一致，更新后系统新的冻结成本也未发生变化。按照系统的原理，此时不应该出现成本更新差异。物料更新前的标准成本与冻结成本不一致的，出现成本更新差异也不是正常更新前后的差额。
3）任务上发生的更新差异，有相当于将成品装配件成本从零成本更新到现有成本时的差异，有的将成品装配件成本从现有成本时更新到零成本的差异，也有数据为（旧成本*2-新成本），金额为现有任务上数量*现有标准成本差异。
4）成本更新只产生了任务上的WIP差异，未产生库存上的成本更新差异。

如此奇怪的问题，我从所未遇。在分析了各种可能出错的情况后，我认为，这种错误不应是个别用户操作引发的，应是系统性的程序出错。经反复检查，多次测试后，终于发现，错误是由一个客户化的成本更新程序引发的，程序运行时，在后台写表时，成本表的某个字段被错误写入，从而引起数据紊乱。在对客户化程序进行修正之后，问题就自然解决。

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

ORACLE ERP系统维护经验谈：四、从全局性出发，处理问题要干净利落，不留尾巴。

系统的维护看似简单，实际上考验着对系统的全面认识。一个问题处理不当，可能会引发其他的问题，问题处理得不完整，当时可能没什么反应，但可能在后续的时间内暴露出其他的问题。ERP不是信息孤岛，各数据之间是相互集成，相互关联，所以处理问题时，要通盘考虑，这个数据与各模块的关联，与各数据的影响，后续影响等，一定要将问题处理得干净利落，不留尾巴。

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

1）问题发生的原因是什么？
2）问题如何解决？
3）相关的引发的问题如何解决？
4）如何从源头上避免问题再度发生。

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

比如：库存科目定义出错，将资产类科目定义成了费用类科目，造成的后果：库存模块产生了大量错误会计分录，并已传送到总账接口，子库科目设置也未更改。

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

错误的原因在于子库科目设置错误，需要进行修改，引发的错误在于会计分录错误，也要修改，同时由于设置的需要，在修改子库科目前必须将现有量清零。

基于此，处理方案如下：

1）清理子库科目需要更改的子库名称；
2）设置帐户别名，用于处理子库科目调整；
3）子库存数据备份；
4）对库存数据做清零；
5）修改子库帐户设置；
6）使用帐户别名将子库数量接收或发放回原子库；
7）从后台更改已产生会计分录的科目代码；
8）注意事项：处理过程中此子库不应进行其他操作，也不能做成本更新。

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

ORACLE ERP系统维护经验谈： 五、举一反三，建立维护问题库。

在维护的过程中，我们会遇到形形色色的问题，在解决问题的同时，我们需要将其记录下来，记录问题发生、解决方案，持之以恒，积少成多，建立问题库，并进行归类，汇总分析，总结经验并寻找规律。这是一个知识积累、知识沉淀的过程，在这个过程中，进行总结、归纳、提升。

这个作用是双面的，一方面是自身的总结提高，以后可快速解决问题；另一方面，也可用来培训客户，提供参考。

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