在ERP項目實施過程中，后院起火是一件非常危險的事情。但是筆者仍然會時常碰到這種事情，讓筆者很難應付。現在筆者就跟大家分享一下，遇到類似事情時的處理方式。希望這些經驗能夠幫助各位項目管理逢兇化吉。
一、 項目實施到關鍵時刻，項目管理員卻跳槽。
讓筆者印象深刻的最大后院起火事件是在給一家企業實施ERP項目進入到關鍵的時刻，這家企業的項目管理員卻跳槽了。當時讓很多人都措手不及。由于一直以來都是這個項目管理員負責這個ERP項目，特別是流程梳理與優化這方面的內容，都是由其主導的。他離職后，在一段時間內ERP項目處于無序的狀態之中。那么遇到這種情況，ERP實施顧問該如何面對呢？
自從這件事情之后，筆者就學乖了。即使企業如何信誓旦旦的保證企業關鍵用戶的穩定性，我們做為實施顧問仍然不能夠掉以輕心。在幫助企業組建項目團隊的時候，都建立企業采取正負責任制。也就是說，項目管理員要設立兩位，分別為正副組長。副組長作為后備，也需要全程參與到ERP項目中來。如此的話，即使正組長因為種種原因最后在中途離開了ERP項目團隊，那么由于副組長參與了整個項目，所以也能夠及時的頂替上來。
這么做的好處，當然是顯而易見的。除此之外，筆者在必要的時候還會跟企業一把手強調項目管理員的重要性。特別會指出如果在項目中途項目負責人中途離場可能會給企業項目帶來的致命打擊。讓一把手真正的重視ERP關鍵用戶、特別是項目負責人的穩定性。防止項目在最后沖刺時，由于關鍵用戶中途退場而導致后院起火事件。
其次，筆者也會強調項目過程中書面資料的整理與歸檔。如在流程梳理與優化的過程中，筆者會讓企業用戶將整理好的流程通過書面的形式記錄下來，并要求有企業一把手或者項目負責人的簽字。如此，即使后續有關鍵用戶或者項目負責人離職，憑借這些書面的資料，新的接班人也可以順利接手。最終的是，通過這些書面資料，可以防止新官上任三把火。將前任項目負責人的工作成果全部推翻。這意味著很多工作將從頭再來，大大的影響ERP項目的進度。
由于項目負責人或者關鍵用戶中途退出項目團隊，會給ERP項目帶來很大的負面影響，甚至是致命的影響。故無論是實施顧問還是企業一把手，在ERP項目開始之前都要能夠清楚的明白這一點。然后根據筆者上面提的一些意見，做好相關的防護措施。最大程度上消除這個后院起火事件給ERP項目帶來的不利影響。
二、 系統跑的正歡，卻發現基礎數據有嚴重的錯誤。
三分軟件，七分實施，十二分數據。這是專家們對ERP項目實施方法論的高度總結。從中可以看出基礎數據對ERP項目的重要性。但是在實際工作中，我們往往會遇到系統跑的正歡，卻發現基礎數據嚴重錯誤的情況。這是繼項目管理員跳槽的第二大后院起火事件。
如筆者以前給一家企業實施ERP項目的時候，就遇到這種情況。他們有一個泡殼的原材料，是存放在包裝材料倉庫中的。但是由于其價值比較大，在統計材料成本的時候，確是計算在零件成本中的。但是企業用戶在產品基本信息整理的時候，沒有發現這個問題。他們將原材料分為包裝材料與零件兩部分。而倉庫也對應的設置為包裝材料倉庫與零件倉庫兩個倉庫。在產品信息導入到系統中的時候，就是按照這個關系來導入的。后來在系統模擬運行的時候，成本會計就發現了問題。系統中產品的零件價格要比實際的低，而包裝材料成本卻比實際的要高出不少。
經過一番查找與分析，才發現是這個地方出了問題。由于現在系統已經處于模擬運行階段，即最后的沖刺階段，卻發生了這種后院起火的時間，讓大家都有點措手不及。最后，根據企業這個實際情況，為了最大程度的減少損失，筆者只好采取了一個折中的處理方案。即將泡殼這種原材料，在設置產品類別的時候，設置為“輔助零件”，并為這個產品類別設置默認倉庫為“包裝材料倉庫”。然后在統計成本的時候，將其與零件統計到一起。這雖然從數字上解決了問題，但是將輔助零件存放到包裝材料倉庫，總覺得有點別扭。不過從當時的情況來看，這也是最好的處理方法了。即使如此，由于涉及到的原材料數量比較多，最后企業還是抽調了很多人員開了一個夜班才將這些內容調整過來。雖然最終沒有給ERP項目帶來很大的損失，但是也讓我們嚇出了一身冷汗。
從這個事件以后筆者學乖了。在整理基本資料的時候，不是一個部門的事情。上了ERP系統之后，各部分數據都是高度共享的。也就是說，每一個基本資料跟各個部門都有緊密的聯系。
防止以后發生類似的錯誤，筆者建議企業項目管理員，在整理某個基本資料的時候，如產品基本信息，最好先列一個固定的格式，如利用Excel表格先將基本資料的格式固定下來，哪些字段是必須填寫的，哪些字段會對其他作業產生連鎖反應等等。然后向各個部分進行確認。根據筆者的經驗，每個部分流轉下來，原先定義的基本資料格式會有60%以上的改動。可見單靠一個部門在定義基本資料的格式，并不能夠反映出各個部分的實際需求。最后的結果肯定是在模擬運行甚至在系統上線之后才發現基本資料的不足。在最關鍵的時刻，后院起火，會阻礙ERP項目的正常上線。
三、 系統正準備上線，卻為垃圾數據煩惱。
企業用戶辛辛苦苦終于引來了系統上線的日子，卻發現系統中存在很多的垃圾數據。這些垃圾數據主要是在前提系統測試、系統培訓的時候遺留下來的。這會大大的破壞用戶的積極性。這又是一起很嚴重的后院起火事件。由于系統中存在不少的垃圾數據，對于系統后續的運行會產生很大的負面影響。如在報表統計、產品導入到處等作業中，都會看到這些垃圾數據的影子，從而影響這些作業的正常運行。這就叫做“一顆老鼠屎壞了一鍋粥”。
很多企業在項目實施過程中都遇到過類似的事件。這主要的責任在于企業的項目管理人員或者實施顧問的身上。其實只要在項目開始之前，稍微做一些防范措施，就可以避免這種情況。如在基本數據建立完成之后，對數據庫進行備份。然后再進行測試與培訓。如此的話，在上線之前，將數據庫還原即可。這就可以消除垃圾數據對項目的負面影響。
除此之外，還可以建立兩個企業實例。現在的ERP系統，很多都支持多企業的。那么我們就可以建立兩個企業，一個企業專門用來后續的測試與培訓；而另外一個企業實例保存的就是企業最真實的數據。而且通過后臺數據庫，還可以讓企業真實的數據同步到測試數據庫中。如此的話，測試產生的垃圾數據也不會影響到企業最后的應用。
可見，只要在項目一開始的時候對這個問題引起重視，就可以采取很多簡單卻行之有效的措施來避免這種垃圾數據對系統運行的不利影響。這個后院起火的事件明顯是可以避免的。這主要看企業項目管理員或者實施顧問是否有這個心了。對此筆者強烈建議，各位用戶對這個問題要引起高度的重視，不要讓一顆老鼠屎壞了一鍋粥。
可以根據ERP系統的實際情況，采取以上幾個措施中的任何一個，就可以輕松的避免這個尷尬的境地。如果不涉及到版權的問題，即ERP企業允許給企業安裝兩個獨立的ERP系統，那么這是筆者所推薦的解決方案。如果軟件公司處于版權考慮不允許這么做的話，那么就建立兩個實例，分別完成不同的任務即可。由于兩個公司的數據相互之間是獨立的，所以也不會對最終的使用產生很大的影響。
轉載請注明出處：拓步ERP資訊網http://www.hanmeixuan.com/
本文網址：http://www.hanmeixuan.com/html/consultation/1082021792.html
相關文章
