系統的遷徙---王紋 孫健

-切換ERP系統的瞬間，你是否有開啟一個神秘盒子的感覺？

---ERP實施的過程好比構築一座嶄新的城市。這座城市乾淨整潔，工商娛樂教育衛生一應俱全且功能強大，交通異常便捷……你充滿希望地構築它，希望早一天離開你現在居住的早已擁擠混亂的村落。但是這座城市建在河的對岸，隨著完工日期一天天地臨近，你發現隔在中間的河又寬又深，要讓村落的子民安然地遷徙到新家去事實上遠比想象的困難。從舊系統向ERP系統的切換就像渡河搬家。事實上很多ERP專案在走完系統配置和測試時看上去都還順利，但在渡河搬家時被淹了個半死。

[@more@]

---簡單的切換計劃

---我們可以從一個虛擬的案例中，理解系統切換的過程。

---李明是一家公司的ERP財務顧問，他目前正在實施的專案包括了幾個主要的模組：財務、銷售、庫存、採購和生產。7月1日，專案經理召開專案組會議討論系統切換計劃。會議上明確了以下幾個決定：

---1． 以8月1日作為本次切換點。

---2． 所有模組同時切換。

---3． 鑑於客戶方的強烈要求，第一個月新舊系統需並行執行。

---由於看上去切換和財務的關係最大，所以專案經理要求李明在會議結束後編制一個詳細的切換計劃。限於篇幅，我們下文的介紹只是整個計劃的一部分：和銷售相關聯的切換計劃。

---期初資料

---李明的計劃首先從期初資料的準備工作入手。“情況稍微有點複雜，但是還難不倒我”，李明想。首先必須兼顧到以下一些問題：

---1. 新系統的期初資料必須和舊系統的完全一致。

---2. 新系統的庫存必須賬實相符。

---3. 7月31日仍在執行過程中的銷售定單，需要作為期初銷售定單輸入系統。

---圖1是從系統切換的角度來看業務，舊系統和新系統的關係。圖1上方是在系統切換日，即7月31日仍未執行完畢的銷售定單。假如某筆銷售定單部分發貨，那麼在7月31日的期末庫存中將不包括已經發貨的產品。我們在7月31日必須進行一次完整的庫存檔點，隨後根據盤點的結果更新舊財務系統的存貨及相關的其他科目。圖1中綠色的箭頭代表了這一過程。

---由於ERP系統是分模組的整合系統，所以不同科目的期初餘額是在不同的模組中分別輸入的，隨後系統自動更新到總賬模組中。圖1下方是本例中涉及的ERP庫存管理模組，應收賬款模組和總賬模組。紅色的箭頭代表了自動更新總賬。由於是分模組的輸入，所以我們專門設定“系統切換過渡科目”，作為所有科目輸入時的對方科目。最後，當期初資料全部輸入完畢後，該科目的餘額應該結平。

---當舊系統7月31日月末結賬完成後，我們將根據盤點的清單和財務上的商品價格，將庫存的期初餘額匯入ERP系統的庫存管理模組。同時將應收賬款的明細科目（明細到未清發票或預付款）匯入應收賬款模組。其他的科目也是分模組按各自的要求匯入ERP系統。圖1中藍色的箭頭代表了這種匯入的過程。由於舊系統的存貨資料已根據實際盤點調整過，所以新系統的庫存管理模組的出發點是賬實相符的（圖1中的紅色虛線）。

---與此同時，對於7月31日未執行完畢的銷售定單，也應當匯入系統的銷售模組。只是不能將整張定單匯入，而是應當扣除7月31日以前已經發貨的部分。圖1左側的藍色箭頭代表了期初銷售定單（Open sales order）的匯入。

---好了，分析完期初資料的準備工作，李明覺得很滿意，畢竟這看上去不太複雜。接下來應該是具體的切換計劃了。

---切換計劃

---圖2是李明設計的切換計劃。首先，在7月20日之前關於庫存地點的系統配置以及所有的物料主資料必須都匯入ERP系統。7月30日也就是系統切換前大盤點的前一天，盤點計劃和盤點表格必須已下發無誤。7月31日停產一天正式盤點。8月1日盤點結束，財務人員彙總盤點結果，開始7月份的舊系統月末結賬。月末結賬預計耗費15天，到8月15日舊系統月末結賬完畢。隨後，資訊科技部和財務部再花2天時間將舊系統的期初資料整理轉化成符合ERP系統匯入的格式。這項工作將在8月17日完成，隨後再花3天將期初資料批輸入ERP系統。這時已經是8月20日了。

---由於第一個月，也就是8月，新舊系統必須並行執行，所以財務部從8月1日起繼續在舊系統中處理業務。這和7月結賬的時間一樣，舊系統在9月15日完成8月的月末結賬。與此同時，從8月20日起所有相關部門都開始在新的ERP系統中處理8月的業務，這樣經過31天到9月20日，新系統在8月份也結賬完畢。隨後用5天時間完成新舊系統的對賬。到了9月25日，整個系統切換工作將徹底完成。我們將完全在新的ERP系統中開始處理9月份的新業務，當然這時仍有25天的工作要追趕，但是經過了並行，加上ERP的強大功能，再加上一點努力，完全可以順利地追上20多天的業務。

---李明的計劃很順利地透過了專案組的審定。激動人心的系統切換就要開始了！

---艱難的切換日誌

---7月20日 事情從一開始就不太順利。這個專案的一個特點就是這家公司的物料主資料非常多，而且各個部門的編碼有很多是不同的。按計劃今天是主資料匯入系統的最後一天，但是別說物料清單（BOM），目前連物料主資料還沒有整理完。專案組和相關的部門領導開了緊急會議，最後制定了緊急計劃：5天內完成物料主資料的整理工作，再用20天完成物料清單的整理，一定要在8月20日新系統執行前匯入系統。專案組的部分物流顧問和關鍵使用者也放下了使用者接受測試（User Acceptance Testing），投入到資料的整理工作裡。最後又晚了兩天才勉強把商品主資料批輸入了系統，幾個顧問和關鍵使用者一連加了幾天班。這時已是7月28日了，庫存管理部門已經來不及按整理後的物料編碼來準備所有的盤點表格了，幾個變化最大的倉庫只能直接用整理之前的編碼做出盤點表格，有些物料甚至沒有編碼，只寫了名稱和規格。

---7月31日 公司停產一天，開始全面的盤點。盤點進行得還算順利，負責庫存管理的顧問和關鍵使用者也參加了監盤。他們回來後告訴專案經理和李明：情況挺好，只是倉管員們對整理後的物料編碼還不太熟悉，基本上都是按名稱和規格來盤點，而且發現好多沒有編碼的物料，只好臨時用名稱來記錄。盤點表已經整理完畢，不過估計財務部使用這些盤點表的時候會有困難。專案經理提醒李明，在財務部結賬的這段時間多去看看。

---8月14日 離預定的舊系統月末結賬完成還有一天，李明真有點著急了，財務部告訴他，可能會來不及。這次上線把原來的一些問題全端到了檯面上，比如說庫存賬實不符，財務部和庫存部門的物料編碼不同等等。這次光是核對和整理盤點報告就多花了一週，新整理的物料編碼錯漏重複不少，而且兩個部門都不太熟悉，特別是對於顧問整理的相當大的部分，客戶方頗有微詞。同時財務經理告訴李明，最後盤點結果，賬實不符的比例可能相當大，幾乎佔了總庫存的20%。當李明問起原因時，財務經理面露難色，說：“不太好說。不過我們不贊成全部算盤盈盤虧，再說稅務局也不會同意。所以最好是掛賬。”李明沒有辦法，只好同意。不過為了掛賬的需要，他又建了幾個科目，因為原來的存貨科目是不允許財務手工更改的。

---8月17日 在晚了兩天以後，財務部終於完成了舊系統7月份的結賬。客戶的資訊科技部把舊財務系統的資料匯入電子表格後就交給了李明。這時是8月18日星期六，資訊科技部的劉工還鬧了個老大不高興。李明找到專案經理，幾個顧問商量了一陣，決定與其爭吵浪費時間，不如顧問自己做整理和匯入。接下來的4天是沒日沒夜的。好在李明的準備工作做得不錯，新舊科目對照表、新舊客戶編碼對照表、新舊供應商編碼對照表等等都在關鍵使用者的合作下準備好了。存貨清單是財務部根據盤點結果和財務資料整理的，和財務賬面的差異的確很大，都轉入了掛賬科目。銷售部門也提供了未清銷售定單的資料，負責銷售模組的顧問在負責匯入新系統。8月22日凌晨，所有的期初資料終於都批輸入了系統，系統切換過渡科目也對平了。此時幾乎所有的顧問都已是精疲力竭，不過大家都很高興，成功彷彿就在眼前。當然，在匯入的過程中，碰到了不少問題，有些得不到的資訊在輸入時只能用“虛擬資產”、“虛擬物料”、“虛擬利潤中心”等等方式臨時處理。不過到目前為止，只落後計劃兩天，大家都很有信心。

---8月22日 從凌晨開始，新系統停機做全備份，上午大部分的顧問都在睡覺。下午李明到財務部轉了一圈，大家都忙著在舊系統中處理業務。財務經理說，新系統期初資料完成已經宣佈了。不過大家今天都很忙，所以沒空在新系統中處理業務，再說對新系統也不熟，培訓是幾個星期前做的，現在都還給老師了。李明問了一下負責物流的顧問們，情況也是如此。

---8月23日 專案經理召集專案組和各部門負責人，重申根據專案計劃我們現在已經落後了，新系統的輸入必須立刻開始，9月20日前必須結束。但是各部門都抱怨說，終端使用者實在沒有技能也沒有信心操作新系統，況且當初的培訓和現在的實際操作是兩碼事。最後平衡的結果是：大部分的顧問都放下手頭的事，全面投入使用者支援，挑選一部分接受能力強的使用者先開始新系統的輸入，隨後再進一步推廣到其他使用者。專案經理又召集了顧問們研究確定：必須強行推進專案，明天一定要開始輸入，哪怕以後這段時間天天坐在使用者旁邊。

---8月24日 在隨後的一個多星期裡，專案組經歷了真正的考驗，輸入工作從一開始就面臨了困難。

---因為輸入的都是8月份已經處理過的業務，所以這僅僅是輸入，而不是業務流程處理。部門間如何在這個過渡階段銜接，是原來沒有考慮到的。比如財務部要做銷售定單開票，卻發現倉管部門的該筆發貨還沒有追加進去，而新的流程要求開票必須有相關的發貨記錄。這時財務只能先跳過這筆業務。第一天李明坐在財務部趙強旁邊，一連五六筆業務都是這樣做不過去，趙強已經唉聲嘆氣了，李明強作鎮定，換了一本費用的憑證，才得以開始。同樣的倉管部門在做發貨時根本無法從舊的發貨單上知道是新系統中哪張銷售定單的貨，幸好新系統的查詢功能還不錯，可以從銷售的商品、客戶等等查詢銷售定單，但是進度和準確性大打折扣。同時也有很多發貨單所對應的銷售定單，銷售部尚未輸入。

---期初銷售定單的問題在第一天就發現了，按計劃銷售部門需要提供的期初銷售定單是必須扣除7月31日以前已發貨部分的剩餘未執行部分。但是銷售部和財務部不同，銷售員們根本沒有像財務這樣嚴格的期間概念。很多的期初銷售定單都沒有扣除已發貨部分或者扣錯了。結果是期初銷售定單可能會被重複發貨。和期初銷售定單相關的業務被暫停處理。銷售員被要求重新檢查期初銷售定單，顧問和關鍵使用者也忙著幫忙手工更正那些原來是批輸入的期初定單。倉管員們和財務部被要求特別留神期初定單。但是，錯誤看來還是難以避免。

---當銷售員開始錄入新的銷售定單時，客戶主資料的問題暴露出來了。之前在準備客戶主資料的時候，曾要求銷售員將現有客戶檔案報給風險管理部統一整理和編號。但是很多銷售員都沒有報全。出於歷史原因，該公司的客戶檔案被銷售員視做個人財產。諮詢顧問在流程設計時也考慮到了這種習慣，雖然公司管理層和風險管理部有許可權看到所有客戶主資料，但是銷售員之間是不能共享客戶資料的。可是沒想到牴觸情緒仍然那麼大，很多銷售員除了7月底財務賬上有的客戶外，其他一律沒有提供。現在要在新系統中管理銷售定單了，可是很多客戶的主資料在新的ERP系統中都沒有，貨發不出去，銷售員們怨聲載道。沒別的辦法，專案組重新要求銷售員上報客戶資料，風險管理部加班加點地輸入客戶資料，由於太零散，也太急，批輸入程式被放在一邊，風險管理部的幾個使用者在銷售員的催逼下已經輸得眼冒金星了。很多資料不完整的只能用預設值應付了。李明在系統中看了一下客戶清單，發現有很多名稱相近的，懷疑是重複編碼了。他報告了專案經理和使用者。專案經理嘆了口氣：“等過了這陣再清理吧。”

---輸入的第三天，負責庫存管理的顧問急衝衝地跑來找李明，倉管員發現很多發貨在系統中無法輸入，原因是這樣的：比如7月31日財務部已經開票，但是在客戶尚未提貨或倉庫尚未發貨的情況下，財務已經在賬上做了結轉成本和確認收入，這樣期初銷售定單中應該已扣除了這筆賬面上的發貨，所以現在實際要發貨時就找不到任何對應的銷售定單。李明立即去問了客戶的財務經理，回答是：“確實存在這種情況，而且數量是比較大的。此外相反的情況也是存在的，比如有些貨已經發了，但是發票還沒有開，所以這些貨在賬上仍然存在。這些就是為什麼庫存賬實不符的重要原因。”李明說：“現在我們必須把這兩種情況的數量都清理出來，重新調整期初庫存，開票而未提的庫存做無賬面價值的處理，發貨而未開票的做虛擬庫存商品。”財務經理搖搖頭：“不可能，現在根本沒有時間和人手整理。”最後折衷的方案是：對於開票未提的，在系統中另外配置一種物料移動型別，財務上的自動記賬設為直接衝期初盤點賬實不符的掛賬科目。對於發貨未開票的情況，實際結轉成本時由財務部直接從掛賬科目中轉出。等過一段時間這些歷史情況都處理完畢後，如果掛賬科目的餘額不顯著，就認為是實際盤盈或盤虧結轉費用，目前暫定為3個月。顧問和關鍵使用者們馬不停蹄地更改系統配置，重新培訓倉管員和財務。李明心中隱隱地不安：“倉管員們如何區分哪些發貨是期初開票未提，哪些是銷售部還沒來得及追入系統的銷售定單發貨。再說，如果期初銷售定單仍然包括了這些開票未提貨，那倉管員將錯就錯地發貨，掛賬科目豈不是總也消不掉？” 不過他實在太累了，只能把這些問題放在一邊，又去幹別的了。

---這幾天還有另一件事令李明非常煩心：從流程上說，財務往往出現在最後階段，往往前面的步驟出錯到了財務這邊就過不去了，比如銷售員追進去的銷售定單及開票申請的價格錯了，等財務追開票過賬時被發現了，隨後遍尋不著那個銷售員，這又大大地影響了財務部的進度，財務部已經被批評了好幾次了，真是百口莫辯。最後李明對財務說，如果錯誤確定的話，就直接改物流的單據吧。但是財務人員大都沒有這樣的許可權，也沒有培訓過物流模組。李明只好一邊加許可權，一邊教，大部分時間還自己直接改物流單據。專案經理對李明說，最好不要自己改許可權，也不要自己改物流單據，應該走流程。李明只好苦笑。

---很多流程被發現存在問題，有些流程還被忽略了，各種配置和主資料也發現各種各樣的問題。本來有些配置和主資料的更改應該走流程解決，但是由於關鍵使用者和終端使用者的訓練不足，現在都直接反映到了顧問這裡。一邊支援使用者，一邊更改配置，李明和他的同事們已經快不行了。而使用者們都在抱怨朝令夕改，永遠跟不上變化。

---不滿的暗流在整個公司擴散。有些從一開始就牴觸ERP系統的銷售員變得更加肆無忌憚，不會操作或不願操作新系統被光榮地掛在嘴邊。連原來支援的員工此時也噤聲了。一個業務員發給李明一篇文章，標題是類似ERP實施成功率為零之類的，是從網上下載的，作者是某國際知名管理諮詢公司的C什麼O。據說這篇文章已經傳遍了全公司。李明怒火中燒。

---吃午飯的時候，李明遇到了趙強，趙強是最早熟練作業系統的財務，所以李明已經好多天沒有去趙強那裡了。李明問趙強情況怎麼樣。趙強說：“苦死了，這個月從月初準備期初資料開始，幾乎天天加班，週末也加班，屁股都像粘在凳子上了。系統要輸兩套，工資倒不發兩份，輸慢了還要捱罵……”李明無言以對，自己也不知道為什麼竟然會感到內疚。

---……

---出現的問題幾乎數不勝數，其他的模組情況也好不到哪裡去，可能還更糟。負責生產計劃的顧問說由於銷售定單的問題和物料清單的不準確，現在執行MRP的結果實在沒法用，況且由於是在追資料，採購和生產目前也用不上新系統的結果，照單據輸就是了。

---專案經理問李明，照目前的情況，將來對賬會不會有問題。李明說：肯定有問題，不過現在顧不了了。

---9月3日 星期一一早，專案組和各部門的負責人開會，討論一個重要的決定：9月份還要不要並行。幾乎沒有什麼爭論就做出了決定：9月份繼續並行。理由很簡單：目前新系統8月的輸入進展實在太緩慢了，什麼時候能輸完對完賬誰都不敢說。現在放棄舊系統，風險太大，沒人負得起這個責任。

---對於新系統大家已經不抱希望能夠追上實際業務了，目前也只能把這次切換和上線作為一次對新系統的測試、驗證和培訓。所以最後決定在公司5個事業部中，挑選兩個配合比較順利的重點突擊，爭取儘快輸完8月份的資料，進入對賬。好在這5個事業部在內部都是相對獨立核算的。

---9月29日 差不多一個月的時間，專案組把所有力量都投入到了兩個選定的事業部中去。終於趕在國慶節前完成了這兩個事業部8月份的資料輸入。但是其他3個事業部的輸入工作幾乎全放了羊。“算了吧，等放完假回來再對賬吧。”李明收拾行李準備回家，“專案要做，命也得要。”

---10月8日 對賬正式開始了，財務部仍然沒有人手可以提供，所有的財務顧問只好都加入了對賬。在開始之前，李明羅列了一下困難和注意事項：

---1. 因為所有模組同時切換，所以相當大部分的財務憑證是透過整合自動生成的，而且在產品成本的核算方法上新舊系統還存在不同，因此無法透過新舊憑證的相互參照號用自己開發的工具軟體自動核對（這種方式稱為自下而上的方式），只能用自上而下的方式核對，即試算平衡表→科目→憑證分組→憑證的方式檢查，對於有些科目如產成品，主營業務成本還要為對賬開發額外的報表。

---2. 必須將新舊系統的資料下載到電子表格後進行核對，發現錯誤時不能直接更改系統，而是在系統外編制調整分錄，這主要是因為參與對賬的人多，而且是分科目對的，對賬人往往又不是記賬人本身，所以如果直接更正系統，極有可能一個錯誤被重複更正。調整分錄的清單是共享的。

---3. 對於新舊系統的差異如何處理是一個不折不扣的難題。如果差異是新系統輸入錯誤造成的，那最簡單，只要調整新系統就行了。但是如果是舊系統輸入錯誤造成的，問題就來了，因為並行階段一般是以舊系統為主，在這個專案中就更是如此了，但是舊系統8月已經結賬，按照規定對8月的調整應該做在發現錯誤的月份，只要還在本年度。所以對賬時只能將錯誤記錄下來，更正到舊系統的10月份，對賬調整分錄仍然是調整新系統。對於因為會計制度變更或核算方式調整造成的差異，更正是不可行的，只能透過報告解釋原因，隨後編制調整分錄調整新系統。此外，由於憑證的數量巨大，而且又不是記賬者自己對賬，所以要找出所有差異的原因幾乎是不可能的。只能參考審計中的重要性原則，找出重要的差異，對於小差異直接編制調整分錄。

---4. 對於調整分錄如何處理，又是傷腦筋的問題。比如由於產品成本核算方式不同造成的差異，透過報表可以解釋差異和編制調整分錄，但是在新系統中如何調整呢？一種方法是根據舊系統的產品成本在新系統中重估庫存，但是這樣做的工作量是相當大的。另一種方法是直接在財務上調整，作類似商品成本差異科目處理，但是這樣做法在以後的月份中還是要考慮它的分攤，等於將工作量向後移了。此外對於沒有找到原因的小差異，直接調整新系統將受到內部和外部的質疑，畢竟所有的憑證都應當有原始支援憑證。不過在這個專案中李明還不用太苦惱，因為並行已經變成了測試，只要找到重要的差異，編制調整分錄將新舊系統報表調平，對賬報告雙方簽字確認就可以了。

---計劃中的5天對賬顯然大大低估了對賬的工作量，雖然5個事業部只核對2個，專案組仍然花了3個星期才透過了對賬報告。專案室裡堆滿了憑證，顧問和關鍵使用者顯得虛弱而亢奮。

---10月29日 在10月的最後幾天，終於對平了兩個事業部8月的賬。接下來怎麼辦？專案組決定用幾個星期的時間重新整理流程和主資料，培訓使用者，隨後清空系統，做第二次切換和上線。當然這次的切換將是嶄新的和成功的。ERP系統的彼岸就在眼前了。

---

---李明的專案只是千奇百怪的系統切換經驗中比較有代表性的一種。事實上沒有兩個專案是一樣的，客戶方行業和文化不同，ERP軟體不同，實施顧問方不同，實施的模組和功能不同，都會使專案的過程產生極大的不同。並不是所有的專案都會經歷這樣的痛苦，個別跨國大公司在中國的推廣專案（Roll-out），比較而言就順利得多。但也有很多專案的情況比這更糟，有些專案因此而失敗了。

---系統切換的經驗

---從李明的專案中，相信大家已經能得到很多經驗和教訓。下面是一些非常有用的經驗供大家參考，當然實際的運用仍然要視專案的實際情況靈活判斷。

---FI-MM方法

---FI-MM方法實質上就是分步切換。這個名稱實際上是兩個經常率先切換的模組的縮寫。我們發現在我國這種分步切換的方法非常具有實際意義：我們首先讓財務和庫存管理兩個模組先切換，隨後銷售、採購、生產等模組再跟進。這種方法至少具有以下一些好處：

---1. 容易控制。相對於所有模組一起切換的大兵團作戰，這種方式更容易控制。而且財務和倉管部門一般較為嚴謹，第一個月先穩住這兩個部門的陣腳，對於士氣會是非常大的鼓舞。

---2. 速度加快。只這兩個模組，在操作上是大大簡化了，系統操作的速度和質量將大大提高。

---3. 對賬簡化。如果第一個月仍然並行，那麼只有財務和庫存管理的新系統和舊系統的對賬就大大簡化了，甚至可以用自動對賬的工具從憑證直接核對。

---4. 期初定單。不再需要準備期初定單了，所有和期初定單有關的錯誤和問題也可以避免了。

---5. 關注新定單新流程。當其他模組跟進時，我們只關心嶄新的業務，比如完全新的銷售定單，我們可以直接用新的流程處理這些定單。而對於期初定單我們不再關心處理它們的過程，我們僅僅是在財務和庫存管理上核算它就可以了，一段時間以後它們的影響將自然地消除。

---6. 大大降低的工作量。

---當然這種做法的缺點也是明顯的：

---1. 最大的麻煩是：相當長一段時間內，有些資訊會丟失或不完整，這主要和期初定單相關。比如盈利分析的資料將不完整，和期初銷售定單相關的盈利分析資料就丟失了。不要低估這一點，因為上線後而看不到完整的報表會使不瞭解情況的領導們非常不高興。因此這個問題一定要在使用前就明確說明。

---2. 切換期間拉長。這不能完全說是一種缺點，因為切換期拉長其實分散了工作量也提高了成功率。但是對於某些條件好的公司，可能因為這一點而選擇更快的全面切換方法。

---3. 更多的系統設定。比如要設定兩套物料移動型別，一套是配合銷售定單、採購定單和生產定單的，一套是獨立的。許可權也需要做相應的設定。不過這個問題不大。幾個人的工作總好過幾十上百個人的混亂。

---總而言之，對於實施困難大，定單執行週期較短的專案，考慮FI-MM方法會有不錯的效果。

---並行和測試、培訓的關係

---並行是一個非常困擾我國ERP實施的問題。我們曾研究過幾種主要的實施方法論（Methodology），但是都沒有發現關於並行的論述。從這個角度看，並行不是一種理想的系統切換模式。並行所造成的痛苦我們從李明的專案中都看到了，但是為什麼並行特別在我國仍然是一種普遍的實踐呢？理由只有兩個字：風險。事實上雖然在我國某些地方財政部門仍強制要求實施ERP系統必須和原系統或手工系統並行一段時間，但是大部分的並行是公司出於風險因素考慮的自主決定。對於這個問題目前仍然沒有一個放之四海皆準的真理。但是下面的分析可能會對決策有所幫助：

---1． 為什麼並行對於系統切換是不利的？

---·目的。並行的目的實質上是對新系統的測試，但是用並行來測試無疑是非常昂貴的，同樣性質的業務要重複地輸入無數遍，最後查出的差異往往只是輸入上的錯誤，對於系統驗證是毫無幫助的。

---·工作量。並行無疑加大了所有系統使用者的工作量。巨大的工作負荷加上對於新系統的陌生和恐懼，使得目標越追越遠，甚至最後不得不放棄。

---·對賬。對於兩套有不同流程、不同概念的系統，即使不存在會計政策的變更，要完成對賬難度也是可想而知的。而且對賬不同於審計，如果並行期間以舊系統為準，那麼新系統最終必須和舊系統完全一致才行，這樣根本無法使用審計中的重要性原則，而只能是完全的核對。

---·審計。不併行並不意味著沒有檢查，新系統仍然必須接受內部和外部的審計。事實上ERP系統提供了比一般會計系統和手工系統更充分的審計軌跡。

---總之，並行的目的是為了防止失敗的風險，而事實是，並行本身是造成失敗的最重要因素之一。

---2． 如果不併行如何防範切換失敗的風險？

---·測試。正如上面所說，並行的目的是對新系統的測試和驗證，所以，如果不併行，就必須強化測試。在李明的例子中，測試就是不充分的。實際上除了對於系統的測試，其他和切換相關的測試也不容忽視：比如期初資料格式轉換和批輸入程式的測試，期初定單特殊流程的測試等等。李明專案的並行實際上已經變成了一次實際資料測試，雖然測得非常全面，但是成本太高了。

---·培訓。在李明的專案中，這次並行的另一個好處是培訓了使用者。所以如果不併行，一定要非常關注切換前期的培訓。

---3． 如果必須選擇並行要注意什麼？

---·FI-MM方法。雖然FI-MM方法無論並行或不併行都有用，但是如果選擇並行，FI-MM方法將增加成功的機會。

---·明確的對賬計劃和手段。確保在切換開始之前，你已經準備好了對賬的計劃和可以使用的工具。

---提高前期工作的質量

---系統切換是專案中第一個“混”不過去的階段。你可以混過現有流程分析階段，也可以混過業務藍圖設計階段，也可以混過系統配置和各種測試階段，同樣可以混過使用者培訓階段和主資料準備，但是系統切換是混不過去的，不但混不過去，而且前期工作的所有問題在這個時候都會反映出來。因此，必須用務實的態度切實提高前期工作的質量，而不只是做出一份文件或者交差了事，這樣，到了系統切換階段才能夠比較順利。

---良好的合作和分工

---在ERP專案中，對於客戶方和實施顧問方來說，成敗是共同的，責任也是共同的。所以真誠而良好的合作和分工，對於專案的全過程有重要意義。但是合作和分工的問題，往往在系統切換前後會暴露得最為明顯。在李明的專案中，顧問們為了追趕進度只能簡化了使用者接受測試去幫助使用者準備主資料，結果系統測試不充分，而資料的質量也成了問題。同時，在本文的最後仍然要強調的是：客戶方管理高層的真正支援，是ERP實施成功的首要因素。

---系統切換的難點

---概括地說，ERP系統切換有以下難點：

---1. 整合。ERP是一個整合的系統，銷售、儲運、採購、生產、會計、資金這些模組和功能不是簡單的加法，它們之間是相互滲透和連貫的。對於日常運作和企業管理，整合具有不可比擬的優點。但是在系統切換時，整合意味著更復雜的切換計劃和對指揮協調工作更高的要求。

---2. 多模組。作為整合難點的推論是：上線的模組和功能越多越複雜，系統切換的困難也就越大，而且難度是成倍增加的。打個比方：2條線相交是1個交點，3條線相交就是3個交點，4條線就是6個交點。整合點會隨著模組和功能的增加而成倍地增加。而且即使使用同樣的模組，由於ERP系統是可配置的，不同公司也會設計出不同的流程。再加上每家公司的實際情況都不相同，這就使得幾乎每家公司的系統切換方式都會有所不同。包治百病的靈丹妙藥是不存在的。

---3. 舊系統。舊系統的資料一般質量較低也較分散（這是可以肯定的，否則也不會有實施ERP的需求）。但是在向ERP系統切換時需要的主資料和期初資料，相當大的部分需要透過加工舊系統資料獲得。因此從這個方面說，系統切換的難度完全取決於舊系統的質量。這裡提到的舊系統，並不單指企業目前正在使用的計算機系統，如果你的倉儲部門仍然在用手工做臺賬，或者你的財務部沒有使用任何會計軟體，那麼這些手工賬也是你的舊系統的一部分。而系統切換最重要的工作之一是資料的轉換。主資料和期初資料主要包含兩大類資料，比如總賬科目（G/L account master），物料主資料（Material master），物料清單（Bill of materials），供應商主資料（Vendor master），客戶主資料（Customer master），工藝路線（Routings），採購資訊記錄（Purchase information records），銷售定價記錄（Condition records (pricing)）等等都屬於主資料。而像期初採購申請（Open purchase requisitions），期初銷售定單（Open sales orders），期初應收應付發票(Open A/R and Open A/P invoices)，期初總賬餘額（Open G/L account balances），期初庫存（Open stocks）則都是期初資料。這兩者共同構成了ERP系統資料的起點。

---4. 舊流程。為什麼舊的流程還會影響ERP系統？道理很簡單，因為舊的流程會影響期初資料。比如舊的流程是始終先發貨，隨後緊接著開票和入賬，還是允許先開票和入賬，以後再發貨或客戶提貨？這會直接影響期初銷售定單和期初庫存。舊流程越不規範統一，系統切換時就越麻煩。

---5. 指揮。困難都是相對的，它遇到卓越的指揮會變得很謙卑，而對於拙劣的指揮它會非常強大。事實上ERP系統切換決不僅僅是實施專案組的任務，它涉及企業很多部門（究竟有多少，取決於實施的模組和功能），因此對於這場戰役的指揮是否成功，取決於指揮官的權柄和能力，取決於部門間的責任和配合，也取決於整個公司的文化。但不幸的是，舊系統和舊流程很混亂的企業，在ERP實施中專案組得到的支援往往也較少。而企業管理高層的支援，無疑是有效指揮的前提條件。

---6. 士氣。我們內心深處都恐懼變化，除非這些變化能給我們帶來看得見的好處。很明顯的一點是：並不是所有的人都願意搬到河對岸的新城市去。如果搬家意味著幾個月加倍的勞動，艱苦的學習和適應，而自己連半句讚揚和肯定都得不到，換了是你，你願意嗎？如果說在專案前期，實施主體是專案組（包括諮詢顧問和關鍵使用者），客戶方的不足還可以由實施顧問方彌補，那麼在系統切換階段，客戶方的很多工作則是外界無法替代的。此時士氣低落意味著時間和資料質量上的失控，無論哪種情況，對於系統切換而言都是致命的打擊。

---7. 並行。系統切換在時間上有嚴格的要求。在系統切換的這段時間裡，有三樣東西可能是並行的：業務，舊系統和新系統。幾乎沒有公司會為了ERP上線而停止業務，因此業務的處理始終在進行之中。那麼對於這段時間業務的記錄是使用舊系統，還是新系統？這是一個艱難的選擇。如果選擇新舊系統並行，那所有相關人員的工作就被加倍了。此外，兩套系統並行必然涉及到對賬的問題，此時系統切換的難度就更增加了。將並行這一難點放在最後並不意味著它不重要，相反，我們的個人觀點是：並行問題成為困擾我國ERP系統切換的頭號問題。我們在下文還會對此有專門的探討。

---世界上沒有兩片樹葉是完全一樣的，每家企業的實際情況相差也會很大。因此，在制定上線計劃時，一定要對上述問題有一個全面的瞭解，見招拆招，而不能生搬硬套。