系統數據遷移的複雜性

您希望將哪些數據從當前系統遷移到新系統?”這一問題的常見回答。這就是一切。雖然這是可能的，但它可能需要比目前正在實施的ERp項目更多的時間和時間。數據遷移子項目中有很多陷阱，但基本出發點是實用的。還應從預算管理部分中注意到，該領域通常在一開始就不在預算內，因此，企業發展 enterprise resource planning 需要進行考慮學生在此階段可以增加多少天的開發量會對預算產生一個什么問題影響。

第一個問題涉及需要數據遷移的業務領域。評估通常可以以數量為基礎。如果有100,000個項目記錄，則將對其進行遷移;如果有10個，則將對其進行鍵控。在對這些量的評估之間有一條灰色線來做出決定。這一行的數量取決於要遷移的記錄的大小和複雜性。另一個可能的解決方案是手動鍵入數據。這本身就可以作為進一步的培訓，如果批量許可，可以將其用於公開的購買和銷售訂單，以消除動態數據遷移的複雜性。一旦確定了自動化技術領域，下一個問題分析就是通過數據本身。數據通常有幾個問題。表的結構將有所不同，一個系統中的概念將不存在，數據本身的質量將很差，這的一個常見示例是地址記錄存儲在完全不同的文本字段中，具有不同的縣級引用，並且無法將它們映射到新的和不同的地址格式，然後可以以不設置現有數據來處理的方式使用新系統。

一種比較常見的要求或要求是要遷移銷售發展曆史數據記錄。要遷移到已發布的賬本表，並將交易標記為全額支付，同時滿足新系統的所有報告要求，這是一個漫長且成本高昂的過程，通常不會產生任何投資回報。一種更有效的方法是將舊數據推送到一個單獨的被引用的SQL數據庫或多維數據集，以便與新系統進行交叉分析，或者只是將數據保存在一個位置供用戶引用。應仔細考慮以任何形式轉換曆史數據的好處、對項目有影響的進度和成本。如果新系統需要不同的設置和分類，而這些設置和分類在當前系統中並不存在，則第一個問題是轉換。最好的方法是，在可能的情況下，在遺留數據的導出例程中創建這些設置。最後一個選項是將它們輸入到要導入的導出數據中——人為錯誤可能會導致問題。

該項目可以與 ERp 實施項目並行運行，並在可能的情況下，對用戶進行遷移數據初始交付培訓。提取、轉換和導入數據的方法和過程因系統而異，但一個共同的因素是內部 it 人員將成為過程的一部分。應當記住，IT 人員通常側重於數據遷移，即將數據從一個字段移動到另一個字段，而不是最終結果是否滿足處理要求。最終的數據例程應該在上線前幾個月確定。在最初測試數據子集時，必須在實時發布之前至少執行一次完整的導入運行，以確保在實時發布日期之前完全理解和解決完整導入中可能出現的所有問題。一旦數據存在並且存在於測試系統中，負責數據的最終用戶必須對其進行徹底測試。最終實現系統中接受最終通過數據的責任在於最終目標用戶，而不是自己負責轉換的IT人員。這意味著要確保從數據遷移項目中獲得最好的結果，必須在上線日期之前沒有完全運行例程，並且我們最終實現用戶管理必須不斷進行分析測試，測試然後再次進行研究測試。