第一篇：ERP系統的切換

ERP系統切換

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

ERP系統

難點

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

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

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

3.舊系統。舊系統的數據一般質量較低也較分散（這是可以肯定的，否則也不會有實施ERP的需求）。但是在向ERP系統切換時需要的主數據和期初數據，相當大的部分需要通過加工舊系統數據獲得。因此從這個方面說系統切換的難度完全取決于舊系統的質量。這里需要解釋幾個概念：<1>舊系統，并不單指企業目前正在使用的計算機系統，如果你的倉儲部門仍然在用手工做臺帳，或者你的財務部沒有使用任何會計軟件，那么這些手工帳也是你的舊系統的一部分。<2>主數據和期初數據，系統切換最重要的工作之一是數據的轉換。這主要包含兩大類數據。比如總帳科目（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系統切換的頭號問題。我們在下文還會有專門的探討。

上面我們介紹了一下ERP系統切換面對的困難。就好比沒有兩片樹頁是完全一樣的，每家企業的實際情況相差會很大。我們在制定上線計劃時一定要對上述問題有一個全面的了解，見招拆招，而不能生搬硬套。

切換計劃

下面這個事例會有助于大家理解系統切換的過程：李明是ERP財務顧問，他目前正在實施的項目包括了幾個主要的模塊：財務，銷售，庫存，采購和生產。7月1日，項目經理召開項目組會議討論系統切換計劃。會議上明確了以下幾個決定：<1> 以8月1日作為本次切換點。<2> 所有模塊同時切換。<3>鑒于客戶方的強烈要求，第一個月新舊系統需并行運行。由于看上去切換和財務的關系最大，所以項目經理要求李明在會議結束后編制一個詳細的切換計劃。由于篇幅所限，我們下文的介紹只是整個計劃的一部分：和銷售相關聯的切換計劃。期初數據

李明的計劃首先從期初數據的準備工作入手。“情況稍微有點復雜，但是還難不倒我”李明想。首先必須兼顧到以下一些問題： 1． 新系統的期初數據必須和舊系統的完全一致 2． 新系統的庫存必須帳實相符 3． 7月31日仍在執行過程中的銷售定單需要作為期初銷售定單輸入系統

銷售定單銷售發貨銷售收款銷售開票銷售部ERP銷售模塊倉庫 舊財務系統銀行存款 XXX應收帳款 XXX存貨 XXX ERP庫存管理模塊商品編碼 數量 單價 總價 庫存地點...WM625 500臺 3,000 1,500,000元 金橋倉庫001 …RF868 1,000臺 4,000 4,000,000元 外高橋倉庫011 …… …… … ERP應收帳款模塊客戶 發票號 金額 付款條款...AAA公司 No.11111 117,000 30天到期...AAA公司 No.11112 234,000 60天到期...BBB公司 No.22222 300,000 30天到期...ERP總帳模塊銀行存款 XXX應收帳款 XXX存貨 XXX… …系統切換過渡科目 0… …圖1：期初數據 圖一是從系統切換的角度來看業務，舊系統和新系統的關系。圖一上方是在系統切換日，即7月31日仍未執行完畢的銷售定單。假如某筆銷售定單部分發貨，那么在7月31日的期末庫存中將不包括已經發貨的產品。我們在7月31日必須進行一次完整的庫存盤點，隨后根據盤點的結果更新舊財務系統的存貨及相關其他科目，圖一中綠色的箭頭代表了這一過程。由于ERP系統是分模塊的集成系統，所以不同科目的期初余額是在不同的模塊中分別輸入的，隨后系統自動更新到總帳模塊中，圖一下方是本例中涉及的ERP庫存管理模塊，應收帳款模塊和總帳模塊。紅色的箭頭代表了自動更新總帳。由于是分模塊的輸入，所以我們專門設置“系統切換過渡科目”，作為所有科目輸入時的對方科目。最后當期初數據全部輸入完畢后，該科目的余額應該結平。

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

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

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

計劃

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

舊財務系統銀行存款 XXX應收帳款 XXX存貨 XXX轉換格式的期初數據完成… …舊系統月末結帳倉庫盤點結束,匯總結果下發盤點計劃和表格2001.07.202001.07.302001.08.012001.08.202001.08.152001.08.17ERP期初數據批輸入完成舊系統數據輸入完畢2001.09.152001.09.20ERP系統數據輸入完畢2001.09.25對帳完成庫存地點和商品主數據輸入ERP ERP庫存管理模塊WM625 500臺 3,000 金橋倉庫001…...ERP應收帳款模塊AAA公司 No.11111 117,000… … ERP總帳模塊銀行存款 XXX應收帳款 XXX存貨 XXX… …系統切換過渡科目 0圖2：切換計劃 由于第一個月，也就是8月，新舊系統必須并行運行，所以財務部從8月1日起就繼續在舊系統中處理業務。這樣和7月結帳的時間一樣，舊系統在9月15日完成8月的月末結帳。與此同時從8月20日開始所有相關部門都開始在新的ERP系統中處理業務，這樣經過31天到9月20日新系統8月也結帳完畢。隨后用5天時間完成新舊系統的對帳。到了9月25日整個系統切換工作將徹底完成。我們將完全在新的ERP系統中開始處理9月份的新業務，當然這時仍有25天的工作要追趕，但是經過了并行，加上ERP的強大功能，再加上一點努力，完全可以順利地追上20多天的業務。

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

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

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

8月14日 離預定的舊系統月末結帳完成還有一天，李明真有點著急了，財務部告訴他，可能會來不及。這次上線把原來的一些問題全端到了臺面上：比如說庫存帳實不符，財務部和庫存部門的物料編碼不同等等。這次光是核對和整理盤點報告就多花了一周，新整理的物料編碼錯漏重復不少，而且兩個部門都不太熟悉，特別是對于顧問整理的相當大的部分，客戶方頗有微詞。同時財務經理告訴李明，最后盤點結果，帳實不符的比例可能相當大，幾乎占了總庫存的20%。當李明問起原因時，財務經理面露難色，說：“不太好說。不過我們不贊成全部算盤盈盤虧，再說稅務局也不會同意。所以最好是掛帳。”李明沒有辦法只好同意。不過為了掛帳的需要，他又建了幾個科目，因為原來的存貨科目是不允許財務手工更改的。8月17日 在晚了兩天以后，財務部終于完成了舊系統7月份的結帳。客戶的信息技術部把舊財務系統的數據導入了電子表格就交給了李明。這時是8月18日星期六，信息技術部的劉工還鬧了個老大不高興。李明找到項目經理，幾個顧問商量了一陣，決定與其爭吵浪費時間，不如顧問自己做整理和導入。接下來的四天是沒日沒夜的。好在李明的準備工作做得不錯，新舊科目對照表，新舊客戶編碼對照表，新舊供應商編碼對照表等等都在關鍵用戶的合作下準備好了。存貨清單是財務部根據盤點結果和財務數據整理的，和財務帳面的差異的確很大，都轉入了掛帳科目。銷售部門也提供了未清銷售定單的數據，負責銷售模塊的顧問在負責導入新系統。8月22日凌晨，所有的期初數據終于都批輸入了系統，系統切換過渡科目也對平了。此時幾乎所有的顧問都已是精疲力竭，不過大家都很高興，成功仿佛就在眼前。當然，在導入的過程中，碰到了不少問題，有些得不到的信息在輸入時只能用“虛擬資產”，“虛擬物料”“虛擬利潤中心”等等方式臨時解決。不過到目前為止，只落后計劃兩天，大家都很有信心。

8月22日 從凌晨開始新系統停機做全備份，上午大部分的顧問都在睡覺。下午李明到財務部轉了一圈，大家都忙著在舊系統中處理業務。財務經理說，新系統期初數據完成已經宣布了。不過大家今天都很忙，所以沒空在新系統中處理業務，再說對新系統也不熟，培訓是幾個星期前做的，現在都還給老師了。李明問了一下負責物流的顧問們，情況也是如此。8月23日 項目經理召集項目組和各部門負責人，重申根據項目計劃我們現在已經落后了，新系統的輸入必須立刻開始，9月20日前必須結束。但是各部門都抱怨說，最終用戶實在沒有技能也沒有信心操作新系統，況且當初的培訓和現在的實際操作是兩碼事。最后平衡的結果是：大部分的顧問都放下手頭的事，全面投入用戶支持，挑選一部分接受能力強的用戶先開始新系統的輸入，隨后再推廣到和支持其他用戶。項目經理又召集了顧問們：必須強行推進項目，明天一定要開始輸入，哪怕以后這段時間天天坐在用戶旁邊。

8月24日 在隨后的一個多星期里，項目組經歷了真正的考驗，輸入工作從一開始就面臨了困難： 1． 因為輸入的都是8月份已經處理過的業務，所以這僅僅是輸入，而不是業務流程處理。部門間如何在這個過渡階段銜接是原來沒有考慮到的。比如財務部要做銷售定單開票，卻發現倉管部門的該筆發貨還沒有追進去，而新的流程要求開票必須有相關的發貨記錄。這時財務只能先跳過這筆業務。第一天李明坐在財務部趙強旁邊，一連五六張都是這樣做不過去，趙強已經唉聲嘆氣了，李明強作鎮定，換了一本費用的憑證，才得以開始。同樣的倉管部門在做發貨時根本無法從舊的發貨單上知道是新系統中哪張銷售定單的貨，幸好新系統的查詢功能還不錯，可以從銷售的商品，客戶等等查找銷售定單，但是進度和準缺性大打折扣。同時也有很多發貨單所對應的銷售定單銷售部尚未輸入。2． 期初銷售定單的問題在第一天就發現了，按計劃銷售部門需要提供的期初銷售定單是必須扣除7月31日以前已發貨部分的剩余未執行部分。但是銷售部和財務部不同，銷售員們根本沒有象財務這樣嚴格的期間概念。很多的期初銷售定單都沒有扣除已發貨部分或者扣錯了。結果是期初銷售定單可能會被重復發貨。和期初銷售定單相關的業務被暫停處理。銷售員被要求重新檢查期初銷售定單，顧問和關鍵用戶也忙著幫忙手工更正那些原來是批輸入的期初定單。倉管員們和財務部被要求特別留神期初定單。但是錯誤看來還是難以避免的。3． 當銷售員開始錄入新的銷售定單時，客戶主數據的問題暴露出來了。之前在準備客戶主數據的時候，曾要求銷售員將現有客戶檔案報給風險管理部統一整理和編號。但是很多銷售員都沒有報全。當然出于歷史原因，該公司的客戶檔案被銷售員視做個人財產。在流程設計時考慮到了這種習慣，雖然公司管理層和風險管理部有權限看到所有客戶主數據，但是銷售員之間是不共享客戶數據的。但是沒想到抵觸仍然那么大，很多銷售員除了7月底財務帳上有的客戶外，其他一律沒有提供。現在要在新系統中管理銷售定單了，可是很多客戶的主數據在新的ERP系統中都沒有，貨發不出去，銷售員們怨聲載道。沒別的辦法，項目組重新要求銷售員上報客戶數據，風險管理部加班加點地輸入客戶數據，由于太零散，也太急，批輸入程序被放在一邊，風險管理部的幾個用戶在銷售員的催避下已經輸得眼冒金星了。很多數據不完整的只能用缺省值應付了。李明在系統中看了一下客戶清單，發現很多名稱相近的，懷疑是重復編碼了。他報告了項目經理和用戶。項目經理嘆了口氣：“等過了這陣再清理吧。” 4． 輸入的第三天負責庫存管理的顧問急沖沖地跑來找李明，倉管員發現很多發貨在系統中無法輸入，原因是這樣的：比如7月31日財務部已經開票，但是客戶尚未提貨或倉庫尚未發貨的情況下，財務已經在帳上做了結轉成本和確認收入，這樣期初銷售定單中應該已扣除了這筆帳面上的發貨。所以現在實際要發貨時找不到任何對應的銷售定單。李明立即去問了客戶的財務經理，回答是：“確實存在這種情況，而且數量是比較大的。此外相反的情況也是存在的，比如有些貨已經發了，但是發票還沒有開，所以這些貨在帳上仍然存在。這些是為什么庫存帳實不符的重要原因。”李明說：“現在我們必須把這兩種情況的數量都清理出來，重新調整期初庫存，開票未提的庫存做無帳面價值的處理，發貨未開票的做虛擬庫存商品。”財務經理搖搖頭：“不可能，現在根本沒有時間和人手整理。”最后折衷的方案是：對于開票未提，在系統中另外配置一種物料移動類型，財務上的自動記帳設為直接沖期初盤點帳實不符的掛帳科目。對于發貨未開票的情況，實際結轉成本時由財務部直接從掛帳科目中轉出。等過一段時間這些歷史情況都處理完畢后，如果掛帳科目的余額不顯著，就認為是實際盤盈或盤虧結轉費用，目前暫定為3個月。顧問和關鍵用戶們馬不停蹄地更改系統配置，重新培訓倉管員和財務。李明心中隱隱的不安：“倉管員們如何區分哪些發貨是期初開票未提，哪些是銷售部還沒來得及追入系統的銷售定單發貨。再說如果期初銷售定單仍然包括了這些開票未提貨，那倉管員將錯就錯地發貨，掛帳科目企不是總也消不掉？” 不過他實在太累了，只能把這些問題放在一邊又去干別的了。5． 這幾天還有另一件事令李明非常煩心：從流程上說，財務往往在最后階段，往往前面的步驟出錯到了財務這邊就過不去了，比如銷售員追進去的銷售定單及開票申請的價格錯了，等財務追開票過帳時被發現了，隨后遍尋不著那個銷售員，這又大大地影響了財務部的進度，財務部已經被批評了好幾次了，真是百口莫辯。最后李明對財務說如果錯誤確定的話就直接改物流的單據吧。但是財務人員大都沒有這樣的權限，也沒有培訓過物流模塊。李明只好一邊加權限，一邊教，大部分時間還自己直接改物流單據。項目經理對李明說最好不要自己改權限，也不要自己改物流單據，應該走流程。李明只好苦笑。6． 很多流程被發現存在問題，有些流程還被忽略了，各種配置和主數據也發現各種各樣的問題。本來有些配置和主數據的更改應該走流程解決，但是由于關鍵用戶和最終用戶的訓練不足，現在都直接反映到了顧問這里。一邊支持用戶，一邊更改配置，李明和他的同事們已經快不行了。而用戶們都在抱怨朝令夕改，永遠跟不上變化。7． 不滿的暗流在整個公司擴散。有些從一開始就抵觸的銷售員變得更加肆無忌憚，不會操作或不愿操作新系統被光榮地掛在嘴邊。連原來支持的此時也禁聲了。一個業務員發給李明一篇文章，標題是類似ERP實施成功率為零之類的，是從網上下載的，作者是某國際知名管理咨詢公司的C什么O。據說這篇文章已經傳遍了全公司。李明怒火中燒。8． 吃午飯的時候，李明遇到了趙強，趙強是最早熟練操作系統的財務，所以李明已經好多天沒有去趙強那里了。李明問趙強情況怎么樣。趙強說：“苦死了，這個月從月初準備期初數據開始，幾乎天天加班，周末也加班，屁股都象黏在凳子上了。系統要輸兩套，工資倒不發兩份，輸慢了還要挨罵… …”。李明無言以對，自己也不知道為什么竟然會感到內疚。… …

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

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

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

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

9月29日 差不多一個月的時間，項目組所有力量都投入到了兩個選定的事業部。終于趕在國慶節前完成了這兩個事業部8月份的數據輸入。但是其他3個事業部的輸入工作幾乎全放了羊。“算了吧，等放完假回來再對帳吧。”李明收拾行李準備回家，“項目要做，命也得要。” 10月8日 對帳正式開始了，財務部仍然沒有人手可以提供，只好所有的財務顧問都加入了對帳。在開始之前，李明羅列了一下困難和注意事項： 1． 因為所有模塊同時切換，所以相當大部分的財務憑證是通過集成自動生成的，而且在產品成本的核算方法上新舊系統還存在不同，因此無法通過新舊憑證的相互參照號用自己開發的工具軟件自動核對（這種方式稱為自下而上的方式），只能用自上而下的方式核對，即試算平衡表->科目->憑證分組->憑證的方式檢查，對于有些科目如產成品，主營業務成本還要為對帳開發額外的報表。2． 新舊系統的數據下載到電子表格后進行核對，發現錯誤時不能直接更改系統，而是在系統外編制調整分錄，這主要是因為參與對帳的人多，而且是分科目對的，而且又不是記帳的人本身，所以如果直接更正系統，極有可能一個錯誤被重復更正。調整分錄的清單是共享的。3． 對于新舊系統的差異如何處理是一個不折不扣的難題。如果差異是新系統輸入錯誤造成的，那最簡單，只要調整新系統就行了。但是如果是舊系統輸入錯誤造成的，問題就來了，因為并行階段一般是以舊系統為主，在這個項目中就更是如此了，但是舊系統8月已經結帳，按照規定對8月的調整應該做在發現錯誤的月份，只要還在本年度。所以對帳時只能將錯誤記錄下來，更正到舊系統的10月份，對帳調整分錄仍然是調整新系統。對于因為會計制度變更或核算方式調整造成的差異，更正是不可行的，只能通過報告解釋原因，隨后編制調整分錄調整新系統。此外，由于憑證的數量巨大，而且又不是記帳者自己對帳，所以要找出所有差異的原因幾乎是不可能的。只能參考審計中的重要性原則，找出重要的差異，對于小差異直接編制調整分錄了。4． 對于調整分錄如何處理，又是傷腦筋的問題。比如由于產品成本核算方式不同造成的差異，通過報表可以解釋差異和編制調整分錄，但是在新系統中如何調整呢？一種方法是根據舊系統的產品成本在新系統中重估庫存，但是這樣做的工作量是相當大的。另一種方法是直接在財務上調整，作類似商品成本差異科目處理，但是這樣做法在以后的月份中還是要考慮它的分攤，等于將工作量向后移了。此外對于沒有找到原因的小差異，直接調整新系統將受到內部和外部的質疑，畢竟所有的憑證都應當有原始支持憑證。不過在這個項目中李明還不用太苦惱，因為并行已經變成了測試，只要找到重要的差異，編制調整分錄將新舊系統報表調平，對帳報告雙方簽字確認就可以了。計劃中的五天對帳顯然大大低估了對帳的工作量，雖然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系統

一個由 Gartner Group 開發的概念，描述下一代制造商業系統和制造資源計劃（MRP II）軟件。它將包含客戶/服務架構，使用圖形用戶接口，應用開放系統制作。除了已有的標準功能，它還包括其它特性，如品質、過程運作管理、以及調整報告等。特別是，ERP采用的基礎技術將同時給用戶軟件和硬件兩方面的獨立性從而更加容易升級。ERP的關鍵在于所有用戶能夠裁剪其應用，因而具有天然的易用性。

第三篇：ERP賬套切換申請報告（寫寫幫整理）

ERP賬套切換申請報告

各位領導：

山西美佳礦業裝備有限公司ERP一期上線供應鏈模塊，至今已經成功運行一年有余。目前整體流程銷售部錄入銷售訂單，采購根據銷售訂單人為查看倉庫庫存及訂單錄入采購訂單，物流根據采購訂單錄入采購入庫單，生產做ERP領料單申請至倉庫，物流根據領料單做ERP領料出庫，生產完工后生產手工開成品入庫單至倉庫，物流根據入庫單做ERP生產入庫，至此銷售錄入ERP發貨通知單，物流根據發貨通知單做銷售出庫。整體流程順暢，倉庫及時庫存準確，基本做到賬物一致。

生產線偶爾會出現停工待料、來料錯誤、用料錯誤等問題，生產用料也沒有得到很好的控制，基本都是生產需要領用多少料倉庫就發多少料，這些都是因為人為的判斷無法得到準確數據，故二期上線生產模塊，通過系統MRP計算用料、領料數據非常必要。上線生產模塊后，采購訂單不是人為的去加請購單、采購單，而是通過MRP系統根據銷售訂單數量及交貨日期結合庫存自動生成采購計劃和生產計劃，采購根據采購計劃自動生成采購單，生產根據生產計劃自動排產、根據生產計劃生成領料單。如此可以避免人為因素，導致采購數量不準確、采購物料錯誤，生產用料錯誤、生產用料得不到控制，交貨延期等一系列問題，這就是ERP生產制造模塊主要解決的問題。

為什么切換賬套？由于ERP生產制造模塊基礎主要是物料清單（BOM）表，前期物料清單已經不支持現階段的生產制造模塊的需求，因此我公司年初就開始對所有物料清單重新制定了規則并且重新編制了新的物料編碼，由于新編碼的重新編制導致業務部門都需要用新的物料編碼來運行業務，故需建立新帳套把之前舊編碼形成的業務數據替換成新編碼的業務數據，經過我們半年的努力舊賬套的數據已經全部替換成新帳套數據并且進行了兩個月的試用行目前運行良好，尚未發現異常情況。

切換并實施ERP生產模塊新帳套勢在必行，以上情況請各位領導知悉。

妥否請批示！

申請單位：山西美佳礦業裝備有限公司

申請日期： 2013年8月11日

第四篇：同類ERP系統

國外

世界上涌現了數百家專門從事ERP產品的開發、銷售和咨詢公司，其中包括Oracle、SAP、BAAN、J.D.Edwards、SSA等。

我國開發的國產ERP系統已有很多品種：如用友ERP、金蝶ERP、浪潮ERP、博科ERI、博通資訊ERP、和佳ERP、金思維ERP等。

第五篇：ERP系統驗收報告

某公司erp服務器及備份系統建設

用戶驗收報告

版權所有 侵權必究 1 驗收時間與地點

驗收日期：2008年 2 月 17 日 驗收地點：某公司中心機房 2 驗收組

用戶方驗收組成員： 用戶方驗收組長：

乙方公司驗收組成員： 乙方公司驗收組長： 3 驗收性質

□初驗 □終驗

驗收依據 5 驗收內容

5.1 提交用戶的文檔清單

驗收人員： 驗收時間： 5.2 系統驗收

驗收人員： 驗收時間： 6 系統整體驗收結論

□通過驗收。

□通過驗收，但還需要需要解決下列問題： 驗收中發現的問題及解決要求/方法（可附頁）：

因為還有一臺pv 132t（lto－2）磁帶庫尚未安裝，則在此進行備注說明：

某公司在需要安裝磁帶庫的時候，必須提前5 個工作日向乙方公司以email和電話確認的方式提出安裝要求。而乙方公司必須安排相應的技術人員到某公司進行安裝調試。

□不通過驗收。

用戶方代表簽字： 乙方公司代表簽字： 日期： 日期：

用戶方蓋章： 乙方公司蓋章：篇二：用友erp項目驗收報告

用友u890軟件驗收報告

陜西塑欣建材有限責任公司

陜西思宇信息技術有限公司

二○一一年十月十五八日

項目驗收報告

一、實施項目回顧

陜西塑欣建材有限責任公司用友u890財務會計系統實施項目從2011年8月15日啟動至今歷時2個月，通過雙方項目組成員2個月的共同努力，目前公司財務部門已開始全面應用用友u890財務會計系統的總賬模塊、固定資產模塊、等子系統來完成日常財務管理工作。

二、項目驗收組織

為客觀評價實施項目的任務完成情況及所取得的成果，合作雙方組織成立項目驗收小組，共同完成對此次實施工作的驗收,小組成員如下：

驗收小組領導層：王瑞（塑欣公司總經理）

李曉剛（思宇公司銷售總監）

驗收小組成員： 雷娟利（塑欣公司財務經理）呂航星（思宇公司用友erp項目經理）李鵬輝（思宇公司用友咨詢實施顧問）

三、實施項目總體評價

項目驗收小組一致認為，系統運行穩定，計算數據準確、信息傳遞及時，實現了最初確定的實施目標：

1．建立了塑欣公司總賬帳套和固定資產帳套。2．在總賬帳套中建立了公司人員檔案、供應商檔案，存貨檔案。3．在基礎設置中錄入了期初余額，增加了二級科目，設置了銀行賬戶。4.在固定資產帳套中錄入了原始卡片及資產增減方式科目的設置。5．在系統管理中增加了操作員，設置了權限；給帳套設置了自動備份。同時，項目驗收小組一致認為，陜西思宇公司u8財務會計項目的實施是卓有成效的。雙方項目組把對軟件系統的理解與對企業管理的深刻認識有機的結合起來，并應用到整個實施過程中。通過規范基礎管理、統一物料名稱和編碼、優化部分業務流程、編制全面的系統應用準則和規程，在系統全面應用的基礎上有

效的促進了企業管理的規范，并將對企業綜合管理水平進一步提高產生積極而深遠的影響。

實施項目的成功得益于以下幾個方面： 1.u8財務會計系統是成熟軟件，適用于制造行業； 2.雙方領導對項目的重視及對項目組工作的大力支持； 3.陜西塑欣公司財務部門對項目組工作的積極配合；

綜合以上各方面因素，項目驗收小組認為陜西思宇公司用友erp—u8財務會計系統實施達到了預期效果，符合陜西塑欣公司提出的管理業務信息化、集成化的基本需求，同意接受該軟件系統投入正常運行，至此該項目的實施工作基本結束，同意對該項目驗收。

此次,在陜西思宇公司進行的用友erp-u8財務會計系統的實施是成功的，在實施項目即將結束之時，對實施項目進行驗收是對雙方實施項目組工作成果的肯定。項目驗收并不表示雙方合作的結束，而是標志著雙方合作新階段的開始。實施項目驗收后，用友公司將一如既往地為陜西塑欣公司提供技術支持服務。按照合同規定，系統啟用后進入運行維護階段，用友公司的實施人員和技術人員繼續根據合同規定負責以后的支持、維護工作。

四、驗收成員簽字 篇三：用友軟件erp項目驗收報告

河北金隆水泥集團有限公司

erp項目驗收報告

客戶項目經理： 日 期： 用友項目經理： 日 期：

1、項目回顧

1.1、實施主要階段

1、項目的實施周期

2、項目實施經歷的主要階段 xxxx集團有限公司業務erp系統實施項目從xx月xx日啟動至今歷時1個半月左右，在xxxx集團有限公司與xxxx有限公司雙方領導的大力支持和關心下,xxxx公司咨詢實施顧問和xxxx集團有限公司erp項目組關鍵成員辛勤努力，先后完成了項目培訓、業務調研、方案準備、方案測試、靜態和動態數據準備、模擬運行以及切換上線等階段性項目任務，各階段工作基本按計劃完成。1.2、系統應用模塊

1、系統上線成功應用的模塊 a． 銷售 b． 庫存 c． 存貨 通過雙方項目組1個半月的共同努力，xxxx有限公司erp系統于xxxx年xx月xx日正式上線。目前xxxx有限公司各相關業務部門已開始全面應用用友erp系統的xx、xx和xx等子系統來完成日常管理工作。

2、項目總體評價

2.1、是否達到項目預期目標

建議描述內容提要：

項目驗收小組一致認為，系統運行穩定，計算數據準確、信息傳遞及時，實現了最初確定的實施目標：

1)建立了共用資料(供應商資料和存貨資料)子系統，對備品備件等物

料實行統一編碼，分倉庫管理，保證了倉庫庫存的實時掌握并供有關部門查詢。2)通過銷售系統的實施，實現了發貨單的機打，和銷售訂單的數量控

制。先后使用了，大量的自定義項目，實現了提貨單提貨時間、包

括格式調整、數量合計大寫、提貨人、車號和訂單余額，等自定義信息，使用了較多的觸發器和自定義函數，基本實現了客戶的個性化需求。3)客戶要求的取貨卡片打印等問題，可通過二次開發實現！4)利用先進的數據庫管理手段，提供先進的報表管理和查詢功能。5)實現了業務管理基本業務信息化和集成化，為企業下一步全面實現

信息化奠定了基礎創造了條件 …………

同時，項目驗收小組一致認為，xxxx有限公司erp系統的實施是卓有成效的。雙方項目

組把對軟件系統的理解與對企業管理的深刻認識有機的結合起來，并應用到整個實施過程中。通過規范基礎管理、統一物料名稱和編碼、優化部分業務流程、編制全面的系統應用準則和規程，在系統全面應用的基礎上有效的促進了企業管理的規范，并將對企業綜合管理水平進一步提高產生積極而深遠的影響。2.2、項目成功的原因

實施項目的成功得益于以下幾個方面： 1)雙方領導對項目的重視及對項目組工作的大力支持； 2)雙方項目經理的實時關注和支持

3)用友erp系統是成熟軟件，適用于工業行業； 4)xxxx有限公司各業務部門對項目組工作的積極配合； 5)xxxx軟件技術有限公司具有專業水準的顧問隊伍。

3、項目驗收

綜合以上各方面因素，項目驗收小組認為xxxx有限公司erp系統實施達到了預期效果，符合xxxx有限公司提出的管理業務信息化、集成化的基本需求，同意接受該軟件系統投入正常運行，至此該項目的實施工作基本結束，同意對該項目驗收。

此次在xxxx有限公司進行的用友erp系統的實施是成功的，在實施項目即將結束之時，對實施項目進行驗收是對雙方實施項目組工作成果的肯定。項目驗收并不表示雙方合作的結束，而是標志著雙方合作新階段的開始。實施項目驗收后，xxxx軟件技術有限公司將

一如既往地為xxxx有限公司提供技術支持服務。按照合同規定，系統啟用后進入運行維護階段，用友公司的實施人員和技術人員繼續根據合同規定負責以后的支持、維護工作。

如果您在用友erp軟件應用中遇到任何問題或疑問

請致電我們的客戶服務熱線：xxxx-xxxxxxxx 我們將竭誠為您服務！

驗收簽字

xxxx有限公司代表

__________________________ 年

月

日

xxxx軟件技術公司代表

____________________________ 年 月 日篇四：erp流程驗收單 erp系統（）模塊_____________流程驗收單

一、功能方面(運營管理部、職能部門)

二、操作方面（使用部門、職能部門）

三、操作手冊（運營管理部、使用部門）

四、表格單據（使用部門、廠長）

五、系統功能確認

六、確認

操作者：

關鍵用戶：

使用部門： erp主數據： 職能部門： 運營管理部： 廠長：篇五：【龍派企業集團nc項目】龍派集團nc-erp系統驗收報告v1.0 龍派企業集團nc-erp系統項目

驗收報告

項目名稱：龍派企業集團nc-erp項目 甲 方： 龍派企業集團

乙 方： 廣東用友軟件有限公司

二〇一一年四月

目錄

文檔控制.................................................................3 1項目驗收的目的........................................................4 2項目驗收的范圍........................................................4 3系統實施的需求來源和實施方...........................................4 4實施計劃和執行情況....................................................4 4.1實施計劃方面：..........................................4 4.2實施計劃執行情況........................................5 5階段成果記錄...........................................................5 5.1模塊應用范圍............................................5 5.2管理提升和價值體現......................................5 6驗收結論...............................................................6 7項目組簽字.............................................................6 文檔控制

文檔密級：機密

根據龍派企業集團nc-erp系統實施的現狀，結合雙方界定項目階段的劃分及項目驗收的基本要求，起草本驗收報告。本驗收報告是按照龍派企業集團nc-erp系統驗收要求的內容、標準編寫。雙方按照如下內容進行檢查、作出結論，并提交本驗收報告。1項目驗收的目的在雙方領導的大力支持下、經過雙方項目組不懈努力和辛勤的工作，龍派企業集團nc-erp系統于2010年11月1號上線。目前系統已經平穩運行五個多月。

項目驗收是對龍派企業集團nc-erp項目組、操作人員及用友實施項目組雙方工作的肯定，對項目進行階段性總結，并標志用友nc-erp系統在龍派集團用戶方基本得以應用。同時項目也將進入維護階段，該階段用友將繼續為龍派企業集團nc-erp系統提供更加適合本階段的服務。2項目驗收的范圍 本次項目按照雙方龍派企業集團nc-erp實施工作任務的要求對以下系統模塊進行實施：uap客戶化平臺、總帳、現金管理、應收應付、存貨核算、采購管理、采購計劃、銷售管理、銷售計劃、銷售價格、庫存管理、內部交易相關模塊的應用。3系統實施的需求來源和實施方

龍派企業集團nc-erp系統的實施是根據雙方簽訂的龍派企業集團nc-erp系統項目合同書所規定的內容并且結合龍牌企業集團的實際業務組織實施。實施工作由龍派企業集團nc-erp項目組同用友龍派集團項目組共同完成。4實施計劃和執行情況 4.1實施計劃方面：

實施計劃分為三個層次，分別為實施主計劃、周計劃，整個項目主體實施在計劃控制下進行。先后完成了項目業務調研、方案定制、系統培訓、錄入數據、系統上線、持續支持等階段性項目任務，各階段工作基本按計劃完成。周計劃是實施中的具體安排，因此未在實施文檔中體現。4.2實施計劃執行情況

主體按照實施主計劃進行實施，局部進行了調整，如果實施計劃有調整，則通過周狀態報告調節，上線時間基本按照實施主計劃的安排執行，會計月度結帳已經基本正常，同時企業日常管理業務已經在nc系統中獨立運行。