筆者曾從事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系統應用與維護水平。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:ORACLEERP系統維護經驗談有哪些需要重要關注的事項
本文網址:http://www.guhuozai8.cn/html/consultation/1082064010.html