ERP專案之實施計劃

賽技術意管理發表於2011-03-26


      
專案成功的關鍵因素是人,包括實施顧問和公司的專案組以及公司的內部員工,還包括潛在的專案利益攸關人。那麼作為重要資源的人,如何在ERP專案中發揮更大的效率,取得專案的成功呢?

二、方案設計階段的詳細討論計劃和二次開發詳細計劃

   
相對於調研詳細計劃,方案設計階段則涉及複雜的公司業務方案抉擇,各個部門的負責人和業務骨幹則需要更多地參與ERP業務方案的討論和決策,花費更多的時間和精力,這就要求專案經理必須在專案實施之初制定方案設計和討論的詳細計劃,部門負責人和骨幹人員必須參與其中。實施顧問根據前階段調研和需求,按照ERP業務的標準流程設計企業的未來ERP業務流程和業務處理方案,但這些方案是否完全符合公司高層和各部門的意願,是否完全適合該企業的業務運作,則需要公司部門負責人、各部門業務骨幹和各業務負責關鍵使用者對ERP解決方案進行充分的學習、理解和掌握,並提出合理化建議。

   
實施顧問對ERP方案的設計從企業高層的角度,站在第三方的立場,並充分考慮企業全域性資源的最優化,但ERP實施應用涉及業務深層次問題,覆蓋整個公司各個部門的業務和利益,則需要高層和部門負責人進行平衡和決策。由於針對企業某一特殊業務,ERP業務解決方案和流程往往不止一個兩個,甚至更多,ERP顧問則需要從不同角度進行分析對比,排比可選方案,分析各個方案的利弊和優缺點。與客戶方各部門負責人和業務顧問以及關鍵使用者進行充分的解釋和說明,並經過方案討論會進行確定。

   
對於業務方案由於各個企業的實際情況不同,對實際業務的處理存在差異,有些是為了簡化工作提高效率,犧牲業務的監控,有些是為了提高業務流程的可控,降低業務和財務風險則需要犧牲一定的工作效率,增加業務流中部分節點的工作量等等,這都需要ERP顧問和客戶方人員在方案講解和討論時,進行深入分析和說明。與客戶方各部門權衡利弊,形成最終的方案。

   
方案設計中,由於企業實情和需求千差萬別,沒有一個標準ERP軟體的功能完全滿足客戶的特殊需求,往往客戶針對ERP軟體提出二次開發的需求,這時則需要顧問進行二次開發需求進行深入的挖掘,找出客戶需求的深層次需求和原因。從以往實施專案我們發現,某個具體客戶方部門或業務人員往往從自身的角度出發,沒有進行深入的分析,二次開發的需求只是問題的表象,抑或客戶方存在某些錯誤的觀念,認為既然請了諮詢公司,沒有做不到的事情,而會片面認為是諮詢公司迴避工作、擔心承擔太多工作等情況。從前一種情況看,則需要諮詢公司的顧問發揮業務專長,從第三方的角度深入挖掘,從業務的源頭開始查詢和解決問題。我們通常說的“透過現象看本質”,就必須通過深入調研,以打破沙鍋問到底的決心,才有可能真正找到問題的根源,對症下藥。對於後一種情況,則需要實施方和客戶方建立更多的信任抑或從實施合同中對ERP二次開發內容和工作進行明確的定義,避免由於雙方的溝通問題產生信任危機,最終導致的結果是雙方的利益都收到了損害。

   
即便已經找到客戶需求問題的根源,而現有的ERP標準功能確實無法滿足使用者的需求時,還不能立即下達開發的指令。畢竟成熟的ERP軟體系統已經過了生產商的嚴格測試才推向市場,特別是大型ERP軟體,如OracleSAP,每個業務模組都是高度整合和統一的。每個ERP二次開發之前,都需要對開發進行可行性的分析,特別是對原系統有流程和結構的較大調整時,可行性分析更是必不可少的重要一環。行業內人士通常把ERP二次開發比喻為一把雙刃劍。二次開發所引發的業務效率、系統穩定性、開發邏輯與原系統機制的衝突和融合等現象,在此不一一列舉。這就要求二次開發必須嚴格遵循軟體工程的方法進行。任何偷工減料的短視行為都會為日後系統缺陷埋下伏筆。

   
目前幾乎每個ERP專案都或多或少存在二次開發,從二次開發工作的開展,就不得不提到各個專案計劃中詳細計劃的其中一項,就是二次開發的詳細計劃。這項詳細計劃由於涉及更多的技術問題,一般由顧問方專案組的開發技術組長負責。二次開發的詳細計劃,包括了詳細二次開發業務調研和分析、需求定義、詳細設計、程式碼編寫和測試、整合測試和上線等幾個方面,除了詳細設計和程式碼編寫外,其餘各項工作都要求關鍵使用者和骨幹業務及終端使用者的參與,對客戶方而言無疑也是一項工作量繁重的任務,也是不可或缺的工作任務。

   
作為方案設計階段的里程碑,方案設計總結匯報會,濃縮了整個專案從調研到設計階段的調研、詳細解決方案(包括二次開發方案)的所有工作,將專案前期的主要成果向企業各個層面進行彙報,也成為下一階段工作的開始標誌。

三、系統培訓詳細計劃

   
從專案調研階段開始至專案上線階段結束,專案培訓貫穿了專案的整個週期,專案系統培訓是ERP專案成功與失敗的關鍵因素。要使使用者能從理解ERP理論開始到完全掌握ERP軟體的詳細操作,就必須進行全面的培訓。從以往的ERP專案實施經驗,我們也都知道,培訓必須貫穿專案的始終,才能使使用者能達到業務熟悉、操作熟練的程度。專案應用成功,大部分來自於使用者對業務的正確理解和準確操作。套用企業管理流行的一句話,一流的員工不是招進來的,而是培訓出來的。在ERP專案實施中同樣適用。但大部分的專案因為專案週期的短暫,往往忽視培訓的投入,培訓人員、場所、環境、教材、器材等都沒有很好的準備,導致大部分培訓流於形式,加上培訓管理不善、參與培訓人員缺乏主動性,導致專案培訓的效果打大折扣。企業使用者的對ERP的學習往往也是三天打漁兩天曬網。而到了系統開始切換上線後,公司業務真刀真槍上線時,員工才發現大部分業務不會操作,臨時抱佛腳的大有人在,關鍵使用者和顧問到處救火的情況時有發生。

   
畢竟ERP專案是對於企業而言是一項投入巨大的專案,公司已經並將為之付出了大量的成本,公司上下不能不說非常重視,則必須建立必要的激勵機制,同時除了公司層面和專案層面建立激勵機制之外,如何有效執行,靠什麼保障呢?從上述培訓問題導致專案問題出發,建立專案完整的培訓體系是非常重要的。不管是專案開始的ERP原理培訓、功能培訓、操作培訓、操作手冊編寫、上崗培訓、崗位指引等到最後的上線指導培訓,都將其納入到專案完整的培訓體系中。當中還包括了對IT專業技術支援的軟體開發員和資料庫管理員的技術培訓等。可謂全面覆蓋了公司的所有層面。

   
針對如此龐大的培訓過程,則要求專案經理編制詳細的培訓計劃,涵蓋專案各個階段的多輪次培訓和各單項的詳細培訓計劃,同時還應該包括培訓後的測驗和上崗考試、操作手冊的編寫、崗位操作指引編寫等內容,計劃必須根據每次培訓的課程和內容,專門指定講師(一般由負責顧問擔任)、培訓教材(由負責講師專門編寫)、培訓場所(指定專人負責)、培訓器材用品(如投影儀、遠端視訊等工具、電腦、區域網或網際網路等)、培訓軟體環境(與公司產品應用環境相同)、培訓物件(一般為關鍵使用者、終端使用者、骨幹業務人員、部門負責人等)、培訓時間(必須保證主要崗位人員都參與)。通過日常上機測驗和上崗考試則對於培訓效果進行跟蹤,將ERP培訓與上崗考試和個人績效掛鉤,作為員工上崗的重要指標之一。

   
對於操作手冊和崗位業務指引的編寫則對關鍵使用者提出了更高的要求,關鍵使用者不僅參與全部的專案過程,還是承載ERP知識轉移的重任,通過操作手冊和崗位業務指引建立企業自身的ERP規範和管理體系。

   
行業有句流行語“進去了如果是垃圾,出來的也是垃圾”。可想而知使用者的正確操作對ERP資料的準確性有不可言喻的重要性。只有業務資料的準確,才能保證專案的成功實施。

專案成功的關鍵因素是人,包括實施顧問和公司的專案組以及公司的內部員工,還包括潛在的專案利益攸關人。那麼作為重要資源的人,如何在ERP專案中發揮更大的效率,取得專案的成功呢?

四、資料收集詳細計劃

   
經過專案詳細方案設計的確認,專案進入了系統建立階段。在方案設計的確認完成後,基礎資料的收集就擺到了專案日程,一個專案實施涉及到企業的基礎資料甚為龐大,解決方案的不同,對資料的要求也不相同。一般靜態基礎資料包括了物料編碼資訊、產品清單資訊、產品工藝資訊、計劃資訊、採購資訊、庫存資訊、生產資訊、銷售資訊、供應商資訊、客戶資訊、財務基礎資料,包括會計科目資訊、資產資訊、成本資訊等。系統上線切換的業務資料則資料量更為龐大。

   
作為業務運作的基礎的資料收集,資料的及時性、有效性、一致性和準確性則是非常關鍵。要求專案經理統籌規劃,具體落實,佈置到人。指定每項資料的要求完成日期、匯入方式、明確責任人和負責顧問,由顧問負責並指導關鍵使用者和終端使用者進行具體每項資料的收集。業務資料涉及到多個部門時,更要安排好具體負責部門和相關配合部門,保證計劃的按時完成,確保上線資料的完整,以保證資料達到上線的要求。

   
安排資料收集計劃的同時,也要求顧問根據各自負責的業務模組,編寫併發布資料收集方案,明確資料收集規範的資料格式,指導使用者嚴格按制定的資料方案和資料格式提交最終資料結果。開始前安排顧問對資料收集方案和格式進行詳細講解,以達到使用者對資料格式的理解與專案規範要求一致。

   
對於收集計劃中匯入方式的選擇不同,可以分為手工錄入、介面匯入等方式。根據資料量的大小和複雜程度不同可由專案組進行選擇。對於採用介面匯入方式的資料,則計劃編排必須保證介面匯入的技術可行性和匯入資料與介面的一致性。這就要求計劃編排必須提前考慮技術人員進行介面匯入程式碼的編寫和測試。此工作可以由技術開發組長進行安排。

   
對於企業歷史比較悠久的公司,基礎資料量的龐大將是非常驚人的。而且舊的歷史資料的格式,不管是手工資料還是舊軟體系統的資料都會與ERP資料的格式要求存在不一致的地方,則需要在系統建立階段開始前,甚至提前到解決方案設計階段開始時,就要開始歷史資料的清理工作,以保證在上線前能完成所有資料的清理工作。如物料編碼的清理、物料清單的清理、供應商和客戶的往來賬清理等,可能由於原公司基礎管理的薄弱,導致資料的清理工作耗費的人力和工時巨大。

五、全面系統測試計劃

   
系統建立階段的另外一項重要工作,就是系統的建立和測試,系統的搭建和設定完全基於解決方案的設計,則必須在前一階段完成的基礎上開展。系統建立後,如何檢驗系統的正確,是否嚴格按照詳細業務方案的設計流程進行業務的處理,則必須經過嚴格的層層測試和把關,專案必須制定嚴格、全面的測試計劃,包括單元測試、UAT測試、整合測試和模擬測試等。測試方案和策略(系統測試業務用例和資料等)的負責顧問、測試時間、測試環境、測試人員、關鍵使用者、參與使用者、測試指導顧問等都要求在測試計劃中全部體現,系統即可以開展全面的測試工作。經過測試後,由測試人員填寫測試報告,以測試計劃要求的測試方案為藍本,填寫具體測試業務的結果資料與模擬使用者的預計結果進行對比,對錯誤的結果進行分析並查明原因,給予糾正。全面測試計劃中,整合測試和模擬測試則必須在單元測試和UAT測試完全正確之後進行。對於這兩項測試要求專案組進行精心的準備,包括系統環境、測試資料、人員安排、場所、時間等。按業務流程指定不同人員進行。測試人員必須是在前期參與專案培訓合格的操作員。整合測試和模擬測試以完成了企業所有業務的閉環處理、輸出各項報表,並輸出最終財務報表為完成標誌。測試報告的最終稽核確認,代表測試工作的全面結束,作為系統建立階段的里程碑,並也標誌這系統建立階段的順利完成。

六、系統上線切換策略和計劃

   
經過了需求分析、方案設計和系統建立階段,完成了需求調研、詳細方案設計、系統設定和資料收集,也就完成了專案的主體工作,到此時,可謂萬事具備只欠東風。系統上線前的最主要工作,也就剩下最後的切換初始化工作。這時,指導初始化工作的系統上線切換策略和計劃,也就是指明系統如何初始化、什麼資料何時初始化、哪些資料先錄入哪些資料後錄入、採用什麼方式錄入以及由誰來負責錄入等問題。由於初始化對各項業務的初始化時間的先後順序要求較為嚴格。這階段大量的準備工作,在資料收集計劃已經完成,則切換計劃要求,明確具體上線時間,由上線時間點倒推各項業務資料初始化的各個時間點、具體業務員、部門負責人、關鍵使用者、終端使用者和負責指導顧問。通過切換策略和計劃,對業務人員進行具體詳盡的指導。保證系統初始化的一次性成功。

   
系統上線切換策略和計劃經過上線討論會議由專案組和公司各個部門各個層面的深入細緻討論,全面溝通達成一致。並在專案上線動員會前統一發布,各部門的具體業務員根據上線切換策略和計劃,按照策略指引按部就班的完成各項初始化工作。當各項準備工作都已經就緒後,在全公司召開專案上線動員大會,專案上線動員會由客戶方專案經理主持,對專案的全部情況向全公司進行彙報,並由公司高層進行全公司的最後上線動員。

   
隨著專案動員大會的召開,也標誌著專案上線階段工作的完成,作為里程碑的標誌。專案隨之也進入了下一個階段也就是執行和維護的階段。

   
縱觀ERP專案實施的各個階段,通過專案計劃體系的運作,支援專案經理總覽全域性,從時間、成本和質量不同角度對專案進行管理。對實施各階段詳細計劃的管控,充分利用資源,控制專案成本和風險,把好專案質量關,以達到為客戶創造良好的效益。

原文網址: http://articles.e-works.net.cn/erp/article62138.htm

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

相關文章