一般來說，企業上馬ERP系統后，都會相應提高關鍵用戶、基層操作用戶的薪籌待遇，但只是從薪籌待遇入手是遠遠不夠的，人力資源方面的一個權威調查顯示，真正因為薪籌流失的員工僅占所有流失量的30%，所以怎樣培養關鍵用戶、怎樣留住他們也成了ERP系統管理的一個重要內容之一。除基本的人力資源手段外，筆者建議:

● 提供不間斷的系統知識培訓。如讀書、ERP系統提供商的培訓、顧問公司講座、參與相關高峰論壇。

● 組織對其他模塊知識的學習和操作。學習其他模塊，了解自己工作節點上下游的操作方法及信息查詢，可以幫助員工了解流程設計原理，清晰流程邊界部門配合工作的重要性，同時也提升了他們的知識儲備。

● 輪崗學習，幫助他們找到對工作的新鮮感，同時培養業務流的意識，使他們成長為BPR(業務流程重組)的中堅力量。

● 鼓勵對系統功能提升的使用發現。通過各類手段，對能夠挖掘出系統新功能的員工進行獎勵，調動關鍵用戶的積極性。

● 除此之外，也要在日常有意識地從基層用戶中選拔苗子，加入到關鍵用戶培養的隊伍中去，不斷地增強后備力量，補充新鮮血液。

5 ERP系統與實際業務結合部的知識管理

如果說戰略規劃是大腦、企業文化是心臟、業務流程是脈絡、ERP系統是骨骼，那么知識管理則是血液，它流轉于整個身體，支持著大腦思維、幫助心臟跳動、聯系脈絡的接點、協助骨骼運動。對ERP系統來講，失去了知識管理就等于人體失去了血液，也便失去了生命力。

對于ERP系統的知識管理，最核心的部分就是與實際業務結合部的知識積累與管理利用。

業務情況千差萬別，問題五花八門，這就需要關鍵用戶們不斷地探討解決方案。大家都知道有了ERP，各部門就都成了一根繩上的螞蚱，誰也離不開誰了，其好處自不必多談，信息統一、集成。但問題就在于，一旦一個環節出現問題，就要求各個相關部門都有動作才可以糾正錯誤，或者說是解決問題。企業的ERP管理部門需要不間斷地收集匯總問題，確立解決方法后，還要不間斷地記錄和總結下來，形成ERP系統的FAQ，放在指定地點統一使用。這樣日積月累，當一個問題重復出現的時候，各模塊操作人員就可以直接調出FAQ按部就班地進行處理，不必再一次溝通、再一次協調、再一次確認。在實際工作中，FAQ著實節省了很多的時間，提高了處理問題的效率和業務響應速度。

同時在實際操作中我們發現，由于ERP系統的基礎數據源豐富，所以在報表取數上就對各模塊的規范操作非常苛刻，沒有整體的知識管理，各模塊面對非常規操作亂下手術刀，其結果是非常可怕的，最嚴重的可能直接造成成本問題及傭金計算問題，使得各部門對系統的可信度下降，其損害程度大不一般。

所以在實際管理中，應當要求各模塊對于非培訓手冊規定內的操作及時向管理部門反映，得到確認后方可繼續操作，隨后補充操作方法入FAQ，形成操作規范體系。

6 業務部門應與技術支持部門緊密配合

筆者認為，如果沒有ERP，信息技術部門永遠不可能真正成為企業運營的一份子，而總是以一個協助者的形象出現，而且多數時候，很少有銷售或者是管理部門會主動地與他們溝通，那么理解公司的運營流程簡直就是不太可能的事情。ERP是一根紅線，它也是使業務與IT結合的紅娘，ERP系統的充分開發和利用使得銷售、人、財、物充分意識到了IT技術的力量，這是任何溝通都不能替代的真實感受。配置修改、報表開發，技術部門也在不斷的需求滿足過程中，鍛煉了自己的隊伍，逐漸熟悉了企業業務流程和各部門開發需求書背后真正的需求目的。作為實際工作的參與者，當看到一次次開發的成果極大地解放了生產力，提高了數據的質量，當年小學課本中的那句培根的名言總是在筆者心中油然而生: “知識就是力量！”

7 加強系統開發及測試工作的專業化和規范化

信息系統的開發過程要制度化，目的是為了最大限度地提高系統開發的工作效率，盡量減少和避免錯誤的發生。

簡單歸納分為以下幾個階段:

1.需求分析及確認(開發人員和相關業務人員進行溝通，形成需求分析文檔)。

系統開發的第一階段尤為重要，它就相當于河的源頭，如果被污染了，河的下游也不會好的。不但浪費開發資源，而且對實際業務也只能是弊大于利。

完成了需求分析書后，要求業務部門進行書面再次確認與簽字。這樣做不但是對需求調研的一個階段性確認，也是需求提出部門再思考的一個過程，切實保證源頭的純凈，并在開發過程中做到有章可循、有法可依。

2.系統設計(可細分為概要和詳細設計，形成技術文檔)。

人們常說：“管理出效益”，ERP系統也不例外！它是一個智商很高、能力很強的“好員工”，但是教它如何適應市場環境、適應團隊整體步調、根據不斷提高的管理需求調整自己的出擊方向，就必須依靠管理。“只有不斷打磨的利器，才有可能路上商戰的變化，適應商戰的需求”。

3.系統開發(主要是編碼和局部測試)。

4.系統測試(由業務人員進行全面的詳細測試，形成系統測試文檔)。

測試文檔的核心部分就是業務情景，沒有多元化的業務情景就非常容易在實際上傳生產系統后出現問題和漏洞。所以測試文檔必須是涉及各模塊聯寫，務必做到詳細、周全，盡量通過業務經驗把可能出現的情況一一道來，一一測過。筆者在實際系統管理中，就經歷過由于測試沒有“盡善盡美”而導致后續的數據垃圾清理起來頗感頭痛的問題。

5.系統驗收(由ERP核心管理部門成員、相關業務人員和開發人員參加，形成系統驗收報告文檔)。

6.后期維護(可能有一些小的修改，但不應有架構性的改動)。

在中小企業的實際管理過程中，如果沒有充足的人力資源支持，至少在第一階段和第五階段，ERP核心管理人員、相關業務部門人員和開發人員一定要進行階段評審，確保業務需求的正確性、合理性、可行性和實用性，保證系統的開發和公司的管理需求及業務流程的改進、優化思路相一致。