ERP項目上線，通常會選擇在五一、國慶、元旦假期，假期前盤點庫存和整理數據，假期中停產停機，便于系統切換上線。那年元旦，我們項目也沒例外，假期前做好上線的準備工作，假期系統部署完畢，生產系統順利切換。在全公司上上下下的殷切期盼中，第一筆業務數據開始錄入，前端平臺通過IDOC再傳到SAP ECC中，就在大家的都覺得進到ECC，在ECC中走完整個流程毫無懸念時，畢竟經歷了這么多輪測試，何況這又是核心流程，可偏偏就在這個節骨眼，卡住了，銷售訂單生成失敗。原本滿心期待還略微有些興奮的項目組同事，頓時出現了短暫停滯，齊刷刷看向我們組，面帶疑惑，不可思議中夾雜著些許憂慮，氣氛驟然緊張了起來，這可是正常的銷售業務流程，沒了銷售訂單，后續所有業務都進行不了，ECC中再好的戲也出不來。
在此當口，我們組同事迅速投入戰斗，從進到ECC的IDOC數據結構開始查起，在極短的時間從數據結構查到程序代碼，期間還接到好幾撥各級領導打進來的關心電話，接這幾通電話的工夫卻啥也沒耽誤，效率反而出奇的高，地毯式搜索后很快鎖定到問題根源，inbound IDOC中的一個字段的數據元素（Data element）被刪除，導致進來的業務數據無法存儲而報錯。
那么，刪除了表結構中的數據元素，那是哪個組的同事干的呢？交叉測試怎么沒有測試到這個問題？還有沒有更多的數據元素也被刪除了？除了銷售訂單的創建以外還會影響到系統其他哪些地方？如果數據元素創建恢復回去會有什么影響？會影響到哪些也用到這個結構的程序和業務流程？
帶著這一堆疑問，在開發配置環境中，從表結構直接查到傳輸請求，很快定位到刪除該內容的請求人和該項目上的開發同事？火急火燎地打通對方電話，邊溝通邊將他們項目的實施和開發同事拉到同一個電話會議上，這才了解到他們項目中由于刪除數據結構中的一個字段，誤刪到了這個數據元素，由于刪除的字段是只有他們項目在用，所以沒有做交叉測試。而這個誤刪的數據元素卻是我們這些個字段共用的，了解了來龍去脈，解決方案也就清晰起來了，但關鍵的是還有沒有別的類似的誤刪？前面提到的這些個疑問如何處理？為解答疑慮，合力研究并核查了系統，反復論證，明確只是一處誤刪，沒有涉及到更多的地方以及其他模塊和項目，并證實將此數據元素創建回去，對方項目不會有影響，同樣不會影響其他的地方，所以最終確定了方案，及時上報后解決此次危機。所有人都松了口氣，各自緩緩的添了杯咖啡。
這樣的畫面，是否似曾相識？歷經ERP項目實施的你，是不是想起一道道再熟悉不過的風景？需求分析、系統測試亦或是上線切換，難免會遇到各種各樣棘手的問題。me too！ 得益于早年系統開發實施以及項目管理的經歷，逐漸養成的ERP項目實施中分析解決問題的三步法，在這么多年的顧問生涯中，一直影響著筆者更加高效解決問題、防止問題擴大化以及預防留下隱患等，在這里和大伙一起提煉并總結：
第一步：解決問題：就所遇問題進行全面檢查，找到原因并及時解決；
第二步：深究根源：進一步深入分析，造成這個問題的根本原因，避免此類問題再次發生；
第三步：追查關聯：追查此問題的關聯方、關聯模塊、關聯業務部門會不會受到牽連或影響，避免問題擴大，繼而影響到相關方或者上下游。ERP系統有其特殊性，是一個高度集成的平臺，供應鏈業務環環相扣，以及與財務業務自動集成，系統內的配置和開發增強也都是有著千絲萬縷的關聯，一旦某處出現問題，難免會波及其余，將問題放到全局中考慮，查漏補缺，能很好的將隱患消滅在萌芽中。負責任的說，在項目中不小心埋藏的雷，含淚也要排完，不然指不定哪天就爆了。
當然，我們也不能只是當項目中遇到問題時才開始這么處理，自我們一開始討論需求、梳理流程以及撰寫開發文檔時，就需要我們對需求或者問題做全面而準確的分析，一是盡可能的窮舉，將需求列全，既有廣度又有深度，還要有時間維度上的考量。二是搜集需求做到不遺漏的同時，還需要我們從具象到抽象的建模中，合乎邏輯的分門別類，做到既獨立又不重疊，業務線清晰。準確反映需求，通過配置或者開發，在ERP系統中完整實現并能讓整個業務流程順暢跑通。
平時面對復雜的ERP系統以及范圍又廣的項目，在項目管理、系統實施以及增強開發等各個角色中的你，希望這簡單三步可以助你更加高效不留隱患的處理問題，交付一個流暢的ERP系統平臺。
