陳先科：實施ERP系統的若干體會(轉)

陳先科：實施ERP系統的若干體會
本人在多年的工作中，參與了ERP的研發和實施，對ERP有較深的認識。在這裡，根據自已的實施過程中的一些經歷，把自已在實踐中的一些體會貢獻出來和大家共享，由於時間和精力所限，內容難免有不當之處，掛一漏萬，僅供參考。

　　國外關於ERP實施的階段劃分是有道理的，只有在這每一個階段的工作都做好了，才能保證ERP的實施成功。現在我就結合這個程式來分析一下ERP實施。

　　1.領導培訓

　　ERP系統被視為一把手工程，對企業高層的領導的培訓是一專案十分重要的工作。而實際情況是如何做的呢？企業領導一般工作比較繁忙，實施企業也出於成本考慮，相應培訓普遍偏少，對ERP的理念作的匯入工作不足，往往影響實施效果。培訓目的是讓他們形成共識，理解為什麼ERP系統是管理改造專案，離不開高層領導的支援；另外一個目的就是讓他們對ERP系統有一個正確的預期。如果，不對高層領導進行培訓，他們對系統的認識不清，他們會認為系統不就是一個軟體嗎？沒有必要投入那麼多的錢。

　　2.需求分析

　　一定要確定好使用者的最終需求。在有的專案，我們認為具體的業務流程我們已經很熟悉了，固然沒有什麼具體協商的。但是到了最後使用的時候，我們就發現我們還是對其詳細操作沒有搞清楚，我知道的業務流程僅僅是一個大體上的概念，對於細節的業務我並不清楚，這個問題是我後來在專案延期的主要因素。

　　確定使用者的最終的需求，根據使用者的需求編制一定的介面，然後根據編制的介面和使用者進行核對，以保證我們表達的和使用者需求的相一致。如果不一致，重新修改我們的介面。

　　根據和使用者討論關於操作問題，這個階段就是搞清楚使用者的檢視，讓終端使用者直接參與專案的開發，當然他們的作用是提供一些參考改進的意見，這些意見是針對終端使用者的操作，目的是讓操作更加貼近使用者。

　　3.BPR

　　在專案的實施過程中，企業管理流程的重組工作往往是最難的。我認為在國企要對企業業務流程作根本性的重組幾乎是不可能的，但一點改進都沒有而要成功地實施ERP同樣幾乎不可能，實施人員提出過對企業工作流程進行改進的建議，往往泥牛入海，沓無訊息。
　　只能根據企業重點控制環節，儘可能多做些改進工作。

　　4.專案組織

　　一般要成立了三級專案組織，企業一把手出任領導小組組長，核心小組、各部門專案組也有相應負責人出任組長。業務問題要在專案組織的會上就能解決，切不可流於形式，讓使用者以工作忙為藉口，不參加工作。

　　5.實施計劃

　　由於ERP涉及面大，計劃的組織工作極為繁重，頭緒極多。專案開始時，不可輕易承諾專案何時完成,一方面，專案剛啟動時，專案的實施範圍通常還比較模糊和抽象、不是很具體。只有等到需求調研以後專案實施範圍才會逐步具體化，即使到這時，專案範圍還存在隨著專案進展發生改變的可能性。

　　另一方面，如果對客戶承諾了一個固定不變最終期限，如果在調研時客戶發現需求和設想有很大不同，比最初專案評估時要複雜的多，因為完成日期已經無法更改，這樣造成的後果是專案組成員需要投入更多的時間或者匆忙之下只能提交一份不令人滿意的解決方案。

　　因此，專案經理必須和客戶溝通，使客戶明白，專案完成日期的確定取決於兩個因素：一是需求調研完成以後，雙方共同確認的專案實施範圍；二是要考慮到專案所需資源約束。這樣如果以後專案範圍明顯地超過最初確定的範圍，專案經理就需要和客戶討論，要麼讓客戶縮小專案範圍，要麼延遲專案完成日期。

　　在ERP專案實施中，必須制定明確的里程碑，以及每個里程碑應取得的成果。專案經理在專案的開始，就需要讓專案組所有成員知道各個階段的里程碑和目標，以及進度的安排、資源的大體上的分配，就好讓專案組的所有成員參與討論，但專案經理應控制談論的範圍，需要避免在專案初期在實施上的分歧。

　　大型ERP專案的實施往往時間很長，這樣專案剛開始，專案組成員有一種錯覺，認為時間還很充足。所以必須對里程碑進一步細分，制定短期的實施目標，讓專案組成員時刻保持高效的工作狀態，如果這些小的目標都能按時完成，那麼整個專案按期完成就有了保證。

　　ERP專案實施時間長，對實施者和客戶來說，成功似乎遙遙無期。如果將目標進行分解，讓實施者和客戶都感覺到一段時間就實現了一個目標，可以激發專案團隊和客戶的積極性。

　　6.培訓工作

　　對於使用者，其關鍵使用者和終端使用者的培訓是不同的，但先培訓關鍵使用者，再由關鍵使用者去培訓終端使用者，這樣是有好處的如：

　　語言上不存在障礙，同樣一個流程或操作，終端使用者一般更容易接受關鍵使用者概念，而我們的概念往往是不能被終端使用者直接接受的，這裡面有行業術語上的障礙，在我們表達上基本上是計算機的術語，而使用者所能接受的是他們行業上的術語。

　　更容易組織，由於我們是外部人事，對於他們我們基本上沒有什麼威懾力，如果有也僅僅是在技術上的敬佩，所以對於企業的協調能力或方式，不能見效，其內容也往往流於形式。

　　(3)自然培養企業內部技術支援路徑，而比直接詢問我們有更好的效果，這樣也會在我們的市場推廣上有較為“陽光”的一面(就是在向其他使用者推廣時採用使用者本身直接介紹的方式)。同時其終端使用者在詢問關鍵使用者問題時，自己也會很好的考慮。(4)鍛鍊關鍵使用者，讓關鍵使用者在培訓別人上對本系統有認識上的提高。

　　7.資料準備

　　資料準備的重要性無庸贅言，要各種場合反覆強調了基礎資料的重要性，並要求企業採取切實的措施來保證這一點。

　　在準備資料之前，成員要準備一份“資料準備文件”，在該文件中要明確如下內容：資料準備時間，範圍。即何時完成，準備何時的資料，準備哪些資料。

　　明確雙方責任。我們一般要求客戶來準備基礎資料，並保證資料的完整性、正確性(實際也只有客戶自己才能做完後，才知道資料的真確與否，一定要盯牢客戶完成資料的測試)；專案組只提供資料準備的要求、格式。

　　資料準備的要求。客戶必須按照專案組要求的格式來準備，這一點非常重要，很有好處：

　　(1)可以保證資料的完整一致。比如說，要準備供應商資料，我們在Excel中準備好空白如下表格。針對這個資訊我們提供的一個更加詳細的說明方式，讓其自由填寫。但以上表格中的資料是必須填寫的。這樣每個準備供應商資訊的人，都知道供應商資料應該包括：供應商名稱、編號、地址、稅號/帳號、聯絡人等。

　　(2)方便核對資料。一旦在Excel中準備好資料，並核對無誤後，就需要輸入系統，輸完以後，再用系統生成並列印報表(但我們沒有這樣做，我們自己準備一個資料庫，在瀏覽器的介面，讓客戶自己直接在瀏覽器的介面填寫，然後提交到資料，這樣就減少了列印重新填寫或匯入的步驟，比如，對上述供應商資料，我們可以從系統輸出一份報表，去和原始的資料核對，看看在輸入過程中是否出錯即可)。

　　(3)如果基礎資料量很大，一般就需要開發專門的資料轉換程式，這樣更需要按一定格式準備資料，否則，資料轉換程式不會正常工作。如果企業本身沒有其他系統(現在一般企業都沒有)，即可讓其直接進行輸入。

　　在實際工作，很多客戶一開始感到不理解，認為沒有必要一定按照某種格式準備，作為成員一定要和客戶溝通，解釋重要性。

　　8.二次開發

　　在市場經濟的調節下，組織變動在公司中是司空見怪的，如果在專案過程中發生的話，其專案內容(人員、系統設定和資料)也必須跟隨著變化，這個變化是很糟糕的。如果變化是頻繁的，所以程式結構和維護流程不停的變更，有時會導致系統實施無期限。

　　ERP設計本身應是靈活的，對於企業結構有一定的適應力，當然在專案中也應該控制企業的變動。這個問題需要分兩方面來看，首先，ERP系統立意要高，要高到和公司組織結構規劃一致(當然對於企業本身也應該考慮企業重組的問題)。其次，就象人在適應社會的變化以前會經歷襁褓期，但我們也該注意在ERP實施的襁褓期減少不必要的震盪，使專案成功完成。

　　9.系統正常執行

　　上述工作均完成後，我們的系統就是要正式執行了。

　　1.驗證設定是否正確。比如各種基礎資料輸入後，經檢查，均正確無誤，但系統生成結果就是不正確。這種情況下，我們就需要檢查是否是設定問題。諸如此類的問題很多，需要一一驗證。

　　2.制訂各種業務規則。上了系統之後，許多新的業務流程和企業原有的業務流程不同，而終端使用者往往習慣了以前的做法，短期內可能不適應。為了確保系統真正用起來，必須做好以下幾點：

　　(1)做好培訓工作。培訓系統的操作和系統的業務流程。

　　(2)制訂詳細的業務規則，規定企業各種業務在系統中是如何處理的。並讓每位相關的終端使用者知道、理解。

　　(3)制訂必要的制度，確保按規定操作，特別是在使用系統初期，完善制度尤為重要。

　　（注：本文作者單位重慶巨集聲新思維資訊產業有限責任公司）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-20420/，如需轉載，請註明出處，否則將追究法律責任。