2.2 ERP集中部署的優勢
2.2.1 ERP集中部署後會大幅降低ERP係統的維護成本。一個ERP係統在正式切換運行後，係統的調整會從上至下適應企業的管理需求，改變了集中部署前在子公司層維護的成本。
2.2.2 降低了係統的建設成本。如果不采購集中建設而是分散建設的話，每個子公司的網絡、服務器、數據庫係統、應用軟件係統投資的總成本將會很大。
2.2.3 管理比較容易。由於數據與應用係統的集中，帶來了係統管理的集中，與分散在各個子公司的係統相比，集中模式更易進行管理。
3 大型企業集團ERP集中部署的信息化的難點
大型企業集團的ERP集中部署工作，不僅是實施一個項目，而且是一項係統工程，本文通過非正式訪談方法，對部分用戶進行訪談，歸納總結出大型企業集團實現集中部署的難點以及處理建議方法：
3.1 對各子公司差異性的處理
3.1.1 係統組織架構標準化的問題。例如：子公司人資的組織管理模塊，可能和全國各公司的結構存在不一致的情況，某些子公司市縣單位在組織管理裏麵是平級結構，而據了解，其他子公司是樹型結構，縣在市下麵。集中部署後對各子公司人資部門的現有管理模式有很大的衝擊，需要了解各子公司情況，確定合理的組織架構方式，對各子公司在組織架構方麵做出大的調整。
3.1.2 項目分類及編碼標準化。例如：某些子公司的設備模塊目前的大修項目分類是按照自身實際業務現狀進行分類的，劃分為生產性計劃修理、生產性非計劃修理、生產性計劃維護、生產性非計劃維護等類別，而其他子公司分為臨時檢修工單、搶修工單、大修工單、計劃檢修工單幾類，各子公司都不一樣。大集中後，標準功能需要和各單位的檢修維護業務緊密吻合。總部需調研各子公司，確定標準的項目類型並予以標準化。
3.1.3 係統配置的細節各子公司不統一。例如：目前各子公司均是基於總部的典型設計，後期其他項目在各子公司的調整存在差異性，很多功能項的配置和選擇是基於各子公司的實際情況開展的。大集中的部署需要考慮這些差異性的消除，並製定合理的方案予以統一。
3.2 業務數據遷移
數據遷移是大集中麵臨的關鍵問題，可能的方案有：
3.2.1 老的業務數據不進行切換，劃定一個時間點，比如201×年1月1日，在此之前的業務，全部在各子公司舊係統完成操作。201×年1月1日以後的新業務，在大集中切換的新係統中操作。此方案相對簡單，但缺點是沒有曆史數據，不利於統計分析和領導決策，也沒有實現“數據延續性需求”。
3.2.2 進行曆史數據的整體的遷移和切換。該方案滿足了“數據延續性需求”，便於統計分析，但工作難度和工作量都非常大，每個子公司涉及幾百G的數據量轉換，涉及到數據庫模型的統一和全部數據的映射轉換。還有舊的業務數據庫中，有很多個性化的部分，很多表結構都進行了增強和調整，還有大量的自建表，這些是很難導入新的總部的標準係統內數據庫裏的。
大集中項目需要順利實施，必須確定一種方案進行數據遷移，兩種方案各有利弊，W集團需權衡利弊後決定。
3.3 外圍係統接口改造
W集團涉及的外圍係統接口較多，大集中勢必要對總部統推或非統推的係統均進行改造，集中部署，但因各子公司的差異，大集中項目的接口改造存在以下兩個問題：
3.3.1 接口改造工作量很大。集中部署後，所有的接口將進行改造。從係統的架構關係來看，目前與總部的縱向接口將改造為橫向接口，而子公司的橫向接口將改造為與總部的縱向接口，同時也要求各子公司要參與新係統接口的開發、測試和聯調工作。若以總部統一標準來執行的話，則所有針對各子公司個性化業務的開發代碼、業務流程、流轉數據等信息要重新開發和部署。目前某些子公司與ERP集成的總部一級部署係統6個，二級部署統推係統18個，非統推係統若幹個。接口大類約有500多個，具體的接口有1200多個，全部改造工作量非常大。