價格調(diào)整以及服務收費超標等事項、行為及其權(quán)責做出預測，并有效約定，從而使信息化項目從一開始就按雙方預定的規(guī)道行駛，互為制約、協(xié)調(diào)，避免再發(fā)意外。
驗收與發(fā)現(xiàn)、檢驗需求并舉。大型的ERP項目不少是邊實施邊驗收，然后再發(fā)現(xiàn)新問題新需求，再進一步返工完善，一步一步地把項目向前推進，但許多中小型的ERP項目最好是成功切換后，錄入一個月以上的企業(yè)重要數(shù)據(jù)，上線運行一個月時間，看看有沒有出現(xiàn)新問題、新需求，如沒有就可進入驗收、簽案。畢竟一個月才是一個小的系統(tǒng)周期，如果小的周期都沒有跑順，就更別說一年這樣的大周期了。如ERP系統(tǒng)能做到平穩(wěn)運行一兩個月以上，能夠準確導出各類月度報表的時候，系統(tǒng)應用和各項業(yè)務操作基本正常、順暢，通常而言，可認為系統(tǒng)已達到的效果或者是達到了先前預定的目標，也說明企業(yè)不再有管理流程、業(yè)務流程新需求與變更了，系統(tǒng)項目可算上線成功了，可以放心驗收、簽案了。
3、項目需求變更的幾項須注意事項
充分交流、協(xié)商。變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件供應商項目經(jīng)理、技術(shù)經(jīng)理必須學會認真聽取用戶的要求、考慮和設想，并加以分析和整理。同時，軟件開發(fā)方應鄭重向用戶說明，進入設計階段以后，再提出需求變更會給整個開發(fā)工作帶來什么樣的沖擊和不良后果，全面權(quán)衡輕重。
區(qū)別對待，折衷求同。隨著項目不斷進展，不少企業(yè)用戶會不斷提出一些在項目實施組看來確實無法實現(xiàn)或工作量比較大、對項目進度有重大影響的需求。
新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的重要依據(jù)。如遇到有些需求無法在短時間內(nèi)解決、需要花個把月才能解決的時候，那就不要硬拼，不要讓項目因此僵住，而要通盤考慮一下，有否臨時的折中方案可以先“應付”一下?如讓用戶先使用現(xiàn)有系統(tǒng)，等過一段時期，技術(shù)解決或二次開發(fā)成功后再給用戶免費升級安裝。
項目越接近收尾階段，再進行需求變更的話，給甲乙雙方造成的損失則越大。因此需求變更要趨早，早提出早好。若你項目快要完工時，才發(fā)現(xiàn)原先的需求有紕漏、缺失，需要變更重設時，那損失就會大了。建房子，若在房子快造好時，卻發(fā)現(xiàn)原先設計不對，需要推倒重來，那成本與時間的浪費就大得不得了。