ERP項目上線，通常會選擇在五一、國慶、元旦假期，假期前盤點庫存和整理數據，假期中停產停機，便于系統(tǒng)切換上線。那年元旦，我們項目也沒例外，假期前做好上線的準備工作，假期系統(tǒng)部署完畢，生產系統(tǒng)順利切換。在全公司上上下下的殷切期盼中，第一筆業(yè)務數據開始錄入，前端平臺通過IDOC再傳到SAP ECC中，就在大家的都覺得進到ECC，在ECC中走完整個流程毫無懸念時，畢竟經歷了這么多輪測試，何況這又是核心流程，可偏偏就在這個節(jié)骨眼，卡住了，銷售訂單生成失敗。原本滿心期待還略微有些興奮的項目組同事，頓時出現了短暫停滯，齊刷刷看向我們組，面帶疑惑，不可思議中夾雜著些許憂慮，氣氛驟然緊張了起來，這可是正常的銷售業(yè)務流程，沒了銷售訂單，后續(xù)所有業(yè)務都進行不了，ECC中再好的戲也出不來。

在此當口，我們組同事迅速投入戰(zhàn)斗，從進到ECC的IDOC數據結構開始查起，在極短的時間從數據結構查到程序代碼，期間還接到好幾撥各級領導打進來的關心電話，接這幾通電話的工夫卻啥也沒耽誤，效率反而出奇的高，地毯式搜索后很快鎖定到問題根源，inbound IDOC中的一個字段的數據元素（Data element）被刪除，導致進來的業(yè)務數據無法存儲而報錯。

那么，刪除了表結構中的數據元素，那是哪個組的同事干的呢？交叉測試怎么沒有測試到這個問題？還有沒有更多的數據元素也被刪除了？除了銷售訂單的創(chuàng)建以外還會影響到系統(tǒng)其他哪些地方？如果數據元素創(chuàng)建恢復回去會有什么影響？會影響到哪些也用到這個結構的程序和業(yè)務流程？

帶著這一堆疑問，在開發(fā)配置環(huán)境中，從表結構直接查到傳輸請求，很快定位到刪除該內容的請求人和該項目上的開發(fā)同事？火急火燎地打通對方電話，邊溝通邊將他們項目的實施和開發(fā)同事拉到同一個電話會議上，這才了解到他們項目中由于刪除數據結構中的一個字段，誤刪到了這個數據元素，由于刪除的字段是只有他們項目在用，所以沒有做交叉測試。而這個誤刪的數據元素卻是我們這些個字段共用的，了解了來龍去脈，解決方案也就清晰起來了，但關鍵的是還有沒有別的類似的誤刪？前面提到的這些個疑問如何處理？為解答疑慮，合力研究并核查了系統(tǒng)，反復論證，明確只是一處誤刪，沒有涉及到更多的地方以及其他模塊和項目，并證實將此數據元素創(chuàng)建回去，對方項目不會有影響，同樣不會影響其他的地方，所以最終確定了方案，及時上報后解決此次危機。所有人都松了口氣，各自緩緩的添了杯咖啡。

這樣的畫面，是否似曾相識？歷經ERP項目實施的你，是不是想起一道道再熟悉不過的風景？需求分析、系統(tǒng)測試亦或是上線切換，難免會遇到各種各樣棘手的問題。me too！ 得益于早年系統(tǒng)開發(fā)實施以及項目管理的經歷，逐漸養(yǎng)成的ERP項目實施中分析解決問題的三步法，在這么多年的顧問生涯中，一直影響著筆者更加高效解決問題、防止問題擴大化以及預防留下隱患等，在這里和大伙一起提煉并總結：

第一步：解決問題：就所遇問題進行全面檢查，找到原因并及時解決；

第二步：深究根源：進一步深入分析，造成這個問題的根本原因，避免此類問題再次發(fā)生；

第三步：追查關聯(lián)：追查此問題的關聯(lián)方、關聯(lián)模塊、關聯(lián)業(yè)務部門會不會受到牽連或影響，避免問題擴大，繼而影響到相關方或者上下游。ERP系統(tǒng)有其特殊性，是一個高度集成的平臺，供應鏈業(yè)務環(huán)環(huán)相扣，以及與財務業(yè)務自動集成，系統(tǒng)內的配置和開發(fā)增強也都是有著千絲萬縷的關聯(lián)，一旦某處出現問題，難免會波及其余，將問題放到全局中考慮，查漏補缺，能很好的將隱患消滅在萌芽中。負責任的說，在項目中不小心埋藏的雷，含淚也要排完，不然指不定哪天就爆了。

當然，我們也不能只是當項目中遇到問題時才開始這么處理，自我們一開始討論需求、梳理流程以及撰寫開發(fā)文檔時，就需要我們對需求或者問題做全面而準確的分析，一是盡可能的窮舉，將需求列全，既有廣度又有深度，還要有時間維度上的考量。二是搜集需求做到不遺漏的同時，還需要我們從具象到抽象的建模中，合乎邏輯的分門別類，做到既獨立又不重疊，業(yè)務線清晰。準確反映需求，通過配置或者開發(fā)，在ERP系統(tǒng)中完整實現并能讓整個業(yè)務流程順暢跑通。

平時面對復雜的ERP系統(tǒng)以及范圍又廣的項目，在項目管理、系統(tǒng)實施以及增強開發(fā)等各個角色中的你，希望這簡單三步可以助你更加高效不留隱患的處理問題，交付一個流暢的ERP系統(tǒng)平臺。