淺析ORACLE ERP系統維護方法

　　ORACLE ERP系統是一個大型集成的軟件系統，是一個企業全面共享的信息數據庫，主要包括制造、分銷、財務等多個模塊，各個模塊相互關聯，數據共享。系統的維護工作包括日常維護及突發事件處理，日常維護是對系統的運行情況做定期或者不定期的診斷、評估，突發事件是對系統中發生的錯誤及異常情況進行診斷、處理。維護工作是一個綜合的業務處理，處理過程可能與操作有關，可能與系統本身相關，也可能兩者兼而有之。系統的維護考驗維護人員的綜合素質，他需要對ERP系統及對企業實際業務都要有全面深入的了解，同時還需要一些技巧的處理。由于ERP系統的全面集成性，所謂牽一發而動全身，一個小小的處理不當，可能引來后患無窮，因此系統的維護需要小心謹慎，通盤考慮。

　　以下為本人在實際工作中的一些經驗總結，結合一些具體的例子，分享給大家。

　　一、要有獨立的判斷能力，學會聽懂用戶的說話，但不要被用戶誤導。

　　我們維護人員常說的一句話，永遠不要相信用戶，要相信自己的判斷。

　　學會認真傾聽用戶的話，但不要被用戶牽著鼻子走。用戶的應用水平參差不齊，表達能力也不盡相同，要明白他們意見背后究竟想要說明的是什么，特別是對那些有一定經驗的用戶，更要認真分析他的反饋，由于他對系統的一些問題認識不足，有時還會誤導你的判斷。

　　ERP系統的問題千變萬化，有用戶操作的問題，有系統的問題，特別是用戶操作層面的問題，更是千奇百怪，有權限的問題，有操作順序的問題，有業務理解的問題，不一而足。同樣的問題癥狀，但不一定是同樣的原因，也不一定適用同樣的處理方法。

　　維護人員接到問題時，不要著急，首先要做的事，要明白用戶是在哪個環節，哪個層面上出錯，一定要調查清楚(這一點在對于遠程維護、電話維護中更加重要)，然后對具體問題進行具體分析。

　　比如有一次，某客戶(企業內部系統維護人員)向我反映，應付模塊中的稅碼全部不見了，問我是不是從后臺做了什么操作。當時一聽到這話，我可是嚇壞了，稅碼的設置只有超級用戶或者系統管理員才有權限，難道有人不小心，從后臺刪除了數據?又或者是系統存在BUG?我首先詢問，有沒人進行后臺操作，回答是無，接著急急忙忙進入系統，查詢之后，發現稅碼設置好好的，都還在。于是，我仔細地詢問了客戶，是什么情況下發現稅碼找不到的，用戶說，昨天還可錄入稅碼的，今天就不行了，我繼續追問，問題具體出現到哪個操作過程中�？蛻粽f是在錄入發票過程中，并說明了具體的發票號。于是，我進入此發票的發票行進行查詢，果然找不到稅碼，真是太奇怪了，設置是正常的，為何就找不到呢?查看其他發票又是正常，看來要從發票本身去查找原因了，我與其他發票認真比較分析之下，發現發票日期有問題，當前年份是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系統應用與維護水平。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]