一、前期的調研
1、時間不足難以進行詳細的需求調研。
公司要求在短時間內開始實施ERP專案。在前期ERP專職人員未到位，專案主管未真正瞭解ERP的情況下，未對軟體供應商做充分的瞭解，而需求是根據軟體公司同行業的經驗，未立足於本公司的實際情況。在選型的時候，基本上不是按我司的需求在對ERP軟體進行選擇。而是按主觀印象與以前的鞋廠的ERP專案經驗在對ERP軟體進行過濾。這樣直接導致的後果就是需要對ERP系統進行大量的二次開發。
即使時間最不足，前期的需求調研仍然不能夠忽視。否則的話，種瓜得瓜，種豆得豆。前面時間雖然省了，但是後期專案推進就會到處碰壁。專案週期反而會延長。確實後來由於很多需求在ERP系統中找不到現成的解決方案，為此，不得不進行很多二次開發，或者尋找其他的替代方法，則大大影響了專案的進度。
2、需求無法對號入座，導致了大量的二次開發。
對於ERP系統這種套裝軟體來說，過多的二次開發是勞命傷財的事情。一方面，過多的二次開發，會破壞ERP系統的穩定性。其次，ERP系統的二次開發，往往需要比較長的時間。有時候，在ERP系統的原有功能上進行修改，比開發一個新功能還要麻煩。因為需要考慮這個需要修改的功能跟其他現有功能的關聯性。而且，還需要進行一些全面的測試。另外，軟體公司出於成本的考慮，也不會配備很多的二次開發人員。公司要進行二次開發的話，往往需要排隊等候。所以，二次開發的週期往往比較長。第三，對於公司說，二次開發往往需要付出比較昂貴的開發費用。大部分ERP系統對於二次開發來說，是獨立收費的。也就是說，不包含在專案實施費用與軟體授權成本中。有些軟體公司甚至對二次開發進行“懲罰性”收費。所以，二次開發的成本往往是比較貴的。
若在選型之前，能夠花這一個半月時間去進行需求調研的話，可能這個EPR專案就不需要進行這麼多的二次開發費用。不但可以幫助公司省下一大筆費用，而且，還可以保證專案的週期。
3、軟體功能不足，卻由公司來買單。
ERP專案能否取得成功，軟體本身只是起到了一個次要的作用。但是，軟體功能不足，則直接跟專案的成本掛鉤。軟體功能欠缺，企業需求難以對號入座，就意味著企業要為此進行額外的開支。如進行二次開發或者採用第三方的外掛等等。這些都是需要公司買單的。而這往往是ERP專案中的冤枉支出。
在實施顧問對公司進行需求調研的時候，發現很多需求無法在ERP系統中實現。但是，這個時候，因為合同已經簽訂，專案已經啟動。所以，對方把一切責任都推到我們這邊。對於無法實現的需求，讓我們公司掏腰包，進行二次開發。
作為企業ERP專案負責人，首先得做好專案的前期需求調研，量體選型，防止企業的常規需求無法在ERP系統中對號入座。從而給企業增加不必要的二次開發成本，影響ERP專案的整個週期。
二、軟體的選型
公司使用ERP軟體，各個部門要達到什麼目標，解決企業目前什麼問題，這些情況公司必須有很清醒的認識，量體選型至關重要。
通常ERP供應商的銷售過程中售前顧問都會拿出一大堆的統計資料，告訴使用者：根據某某某協會統計ERP專案實施完畢之後，企業的庫存積壓率會下降多少個百分點、生產效率會提高多少多少，銷售的反應速度又會提高多少多少。但在合同中軟體公司是不會註明這些的，這就帶來了ERP專案的第一個陷阱：不承諾效果。
ERP專案是公司內部的事情，諸如人事調動、流程修改等等，都不能直接的產生效率，即使是將這些結果數字化也很難分清楚，什麼是通過實施ERP產生的，什麼是企業流程優化而產生的。作為軟體供應商來說，成功了，自然是他們的功勞，可以大肆宣傳，失敗了就是企業內部的問題。他們只需要到時間收錢就好了。然而這樣的承諾，公司是不能接受的。
當然，售前活動中誤導使用者是很正常的，不誤導你，你又怎麼會心甘情願的籤合同呢。
另外，軟體的選型之前，ERP專職人員必須先期到位，做好前期的調研，收集各個部門的功能需求及各種表單，ERP專職人員協同各個部門主管參與ERP供應商對ERP軟體的功能演示．根據收集到資訊，確認ERP軟體是能達到及滿足公司各個部門的要求．以公司的真實業務資料流進行資料演示．在關鍵點位置必須進行壓力測試，因部分功能如MRP計算，憑證傳輸等，涉及到計算的情況，資料量一大，程式是否能正常進行，執行效率是否能達到要求，必須有先期的預測。
所以在選型之前，企業應該明確：
1、企業實施ERP目標。
2、軟體公司的實力及其成功的案例，軟體公司能做什麼。
3、ERP軟體單元測試 壓力測試 全面測試。
4、對於銷售人員的承諾一般需要對企業進行詳細的調研以後才能做出，要在合同的補充附件中給予規定。讓口頭保證有書面規範，合同保證。
三、合同的簽訂
合同的簽訂必須有利於公司一方．以免公司在ERP使用的過程中吃啞巴虧，使ERP的成本儘量透明化，減少隱性成本的開支，讓軟體公司提供儘可能優質的服務，從而儘量保證ERP整個專案的推動過程，不因二次開發費用問題＼培訓問題＼顧問週期問題等而發生不必要的麻煩，從而影響到整個ERP專案的週期．對於軟體公司來說，保護自己的利益是正常的事情，而對於使用者來說則恰恰相反。在簽訂ERP合同的過程中光法律顧問的指點是很難防範軟體公司在ERP合同中設下的圈套。這就需要公司能充分了解ERP這個行業的特徵，避免更大的風險。
1、二次開發的定義
二次開發的具體內容（大至範圍），提供的服務，進行的方式和確定開發費用的範圍。軟體公司最常見的手段是：在ERP合同中只註明二次開發的人/天數（一個人工作一天的費用），而將具體的開發費用拖到合同完成以後。以還未做深入評估為由拖延開發的時間。待到合同簽訂使用者已支付定金之後，以各種藉口增加二次開發的時間。畢竟評估一個開發過程需要多長的時間是由軟體公司決定的。對於某些難度大的或者是軟體公司不想做的專案他們可以把開發的時間加得很大――企業基於成本的考慮，不得不取消某些計劃中的需求。曾有ERP銷售人員這樣對我說：“二次開發是制約使用者強有力的手段之一，要麼他們精簡流程，要麼支付更多的費用，兩樣我都喜歡”。
2、實施週期的定義（專案計劃）
乙方必須在約定的服務人天內安排所有系統整合及實施工作，不得隨意增加計費服務時間，如因甲方原因造成超出合同約定實施天數的費用部份由甲方承擔，如因乙方原因造成超出合同約定實施天數的費用部份由乙方承擔。
3、專案驗收標準（專案交付的檔案）
甲、乙雙方確定專案階段性驗收及最終驗收的標準，驗收行為應包括：
a)甲方對乙方提供的ERP軟體產品的驗收；
b)甲、乙雙方對於某具體工作成果的確認；
c)根據合同規定的專案進展階段，甲、乙雙方對於某階段工作成果的評價；
d)甲、乙雙方對於最終工作成果的評價。
4、雙方的職責定義
按照軟體公司提出的建議劃分權責――作為公司必須做哪些工作，作為軟體供應商必須保證哪些。
5、培訓的定義（包括培訓方式，培訓物件，培訓時間表，培訓文件或教材，培訓成績考核，培訓評估等）
考慮到企業未來的內部培訓需要，軟體公司提供的文件必須以電子文件和紙張的形式提供。
6、專案各階段的目標與任務
按照專案建議和企業的實際情況制定ERP系統的實施目標。
7、簽訂補充協義，說明，備忘錄
在簽訂ERP合同之前就必須要對ERP專案的驗收標準有一個清晰的認識，同時在合同簽訂之後必須有相應的驗收細節作為補充。
8、專案顧問資歷＼時間保證＼顧問更換＼人天數投入＼顧問實施工作時間（是否駐廠等）
9、失敗後的賠償
通常軟體公司是不願意提到賠償字樣的，即使是有賠償，那也是客戶未按期付款需要賠償，不小心被發現了也以“失誤”來掩蓋。ERP實施的成果難以判斷，責任的歸屬難以判斷，最終賠償的問題也容易帶來很多麻煩。這和普通商品的買賣不同，質量不好可以退貨。
正因為如此，需在合同上增加條款：明細專案目標，劃分權責，如果因為軟體公司的原因導致專案延誤甚至是專案中止，軟體公司需要進行相應的補償。
四、顧問的能力
一般顧問有以下幾種型別：技術支援型，幫助客戶安裝ERP軟體，並對客戶進行操作培訓；程式設計師型，工作內容以客戶化為主；顧問型，從為客戶提供業務諮詢服務著手，幫助客戶進行業務重組並指導客戶成功應用ERP。
在提交ERP專案建議的過程中，部分軟體公司也會同時提交ERP顧問的簡介資料――但顧問的簡歷往往有摻假的成分。至於軟體公司提交給公司的顧問資料中是否將只有幾個月某ERP產品經驗的“顧問”吹噓成3年五個專案經驗高階顧問。同樣的，沒有某個行業經驗的顧問也會吹噓成具有該行業或專案經驗。但問題的關鍵還不在於此，更多的是高階顧問只在專案中掛有一個頭銜。而實際的工作則是由毫無經驗的顧問進行。或者專案的調研與系統分析階段由高階顧問去做，後期的培訓以各種理由將高階顧問調離，用中低階顧問替代，這樣的情形對於使用者來說毫無辦法。當然，軟體公司在專案的進行中也有可能會遭遇人才流動。
故，所有的顧問必須經過考核或認可後才能上崗，對於顧問的更換必須經過企業的同意。
由於顧問的能力問題導致的專案拖延，軟體公司必須承擔相應的責任。
前期BOM表的錄入，顧問指導時發生多次BOM變更錄入方式及對物料半成品編碼及名稱定義不清楚，造成BOM資料資料錯誤，後期花費大最的時間和精力去一種一種類別，一個一個錯誤的修改．直接影響到專案的週期。
五、確定詳細的專案實施範圍、定義遞交的工作成果、評估實施過程中主要的風險、制定專案實施的時間計劃、成本和預算計劃、人力資源計劃
A、確定詳細的專案範圍：對公司進行業務調查和需求訪談，瞭解使用者的詳細需求，據此制定系統定義備忘錄，明確使用者的現狀、具體的需求和系統實施的詳細範圍。
B、定義遞交的工作成果：公司與實施軟體公司討論確定系統實施過程中和實施結束時需要遞交的工作成果，包括相關的實施文件和最終上線執行的系統。
C、評估實施的主要風險：由實施軟體公司結合公司的實際情況對實施系統進行風險評估，對預計的主要風險採取相應的措施來加以預防和控制。
任何管理變革專案都有風險，因為它是在進行變革，ERP專案更是如此。在專案規劃之初就要充分考慮到各種風險，有評估計劃和應對措施。專案實施過程中，風險高的事項一定要謹慎行事，即使工期稍微延遲一下，倘能控制風險那一定值得。
費用超預算了、組織人員變更了、專案經理更換、需求變更、高層失察、顧問更替了……
D、制定專案的時間計劃：在確定詳細的專案範圍、定義遞交的工作成果和明確預計的主要風險的基礎上，根據系統實施的總體計劃，編制詳細的實施時間安排。
E、制定成本和預算計劃：根據專案總體的成本和預算計劃，結合實施時間安排，編制具體的系統成本和預算控制計劃。
F、制定人力資源計劃：確定實施過程中的人員安排，包括具體的實施軟體公司的諮詢人員和公司方面的關鍵業務人員；對使用者方面參與實施的關鍵人員，需要對其日常工作作出安排，以確保對實施專案的時間投入。
六、明確專案小組成員職責
A、ERP系統管理員的職責
ERP管理員在整個ERP實施過程中扮演著極其重要的作用，是ERP系統實施成敗的關鍵因素之一。其主要職責是組織、計劃、實施、反饋，應賦予足夠許可權。
B、ERP系統專案副組長的職責
全面負責ERP的日常工作，在系統管理員的配合下對ERP專案進行有效管理。
C、ERP專案各部門組長的職責
在實施過程中部門組長的職責是：傳、幫、帶。將ERP思想及軟體功能消化後傳入本部門、向部門傳遞領導的指示及對ERP工作的要求、將部門業務傳遞給實施顧問;幫助制定業務流程及操作流程、幫助指定人員分工及明確職責、幫助跟進資料及監督專案進度、配合實施顧問工作;帶是帶領部門人員收集資料、配合實施顧問培訓終端使用者、指導部門正確使用系統開展業務。在正式應用過程，組長應該是部門的精英。所以在指定專案核心組人選時，必須慎重考慮，必須考慮這些人員的綜合業務能力及對企業的忠誠。如果組長是兼職的，勢必受日常工作影響而不能在ERP專案上投太多的時間，沒能吃透ERP的內容。所以要求各部門組長有較強的業務綜合能力、工作協調能力和領導能力。
D、專案負責人及實施顧問的職責
ERP顧問是企業實施ERP系統強大的.外部推動力。ERP顧問的作用是對企來進行ERP理論和軟體培訓、管理諮詢、指導，更重要的還是如何幫助企業進行仲裁。ERP顧問能否控制整個實施過程、能否正確引導、能否對問題作出仲裁對ERP能否成功實施是很關鍵的，既不能軟體完全跟著企業業務走，也不能企業業務完全跟著軟體走，而應該相互調各，走最高效快捷的道路。從另一方面來說，ERP顧問也不是萬能的，所有事情都是他做，他只是引路者。可將他比喻成足球教練，他負責指揮球隊怎樣踢球，採隊什麼技巧進攻，但教練是不進場踢球的，就算是進場更不能完全依靠他進球。
主要職責是：
1．對ERP專案進行有效的專案管理，制訂實施計劃，控制好實施進度，分配好實施任務，並進行有效的跟蹤和反饋。
2．對ERP軟體進行有效的不同層次的培訓和操作指導併合理有效安排、監督和考核企業內部培訓。
3．同管理員一起及時解決實施過程中出現的諸多問題，針對軟體本身的問題及時反饋並解決。
4．對ERP操作、使用情況進行部門和人員的考核。
5．對企業的ERP應用提供管理資詢，如流程變更等。
在ERP系統管理員的配合下對ERP專案進行有效果控制和實施推進。
E、ERP各部門組員的職責
1、日常ERP單據及基礎資料的錄入工作。
2、日常資料的稽核工作。
3、向ERP系統管理員反映在ERP執行過程中出現的問題。
4、嚴格按照《ERP作業指導書》進行ERP系統的日常運作。
七、基礎資料的準備
ERP的主要作用就是對企業資訊的整合，而資訊的載體和表達都要通過資料完成。對專案實施來講，基礎資料的準備工作難度最大。
首先，基礎資料涉及面廣，涵蓋了企業中所有可見資訊和不可見資訊。物料基本資訊，產品結構資料，會計科目，供應商客戶資訊，部門、工廠、倉庫、車間資訊等等屬於可見資訊，這些資訊在手工作業中也會用到。不可見資訊如單據型別、倉庫性質、計劃引數等，這些資訊在手工管理資訊時是不會涉及到的，它們會影響到系統計算。
另外，基礎資料準備的工作量大，以上各類資訊的記錄數從幾個到幾十萬都有，而每條記錄包含的欄位又可多達上百個，兩者的乘積簡直是天文數字，通常造成專案延期的原因有90％來自於基礎資料整理。
資料的正確性是最重要的，基礎資料是許多程式正確執行的基礎，如物料計劃和生產計劃就是根據物料檔案設定的提前期、庫存量、BOM結構等計算得到的，如果其中任何一個數據與實際不符，計劃結果就將沒有任何指導意義。
正是因為基礎資料具有這些特徵，從而造成了收集準備工作量大、難組織，一般需要多個部門協調，投入的人力和時間都比較多，見效週期長，因此阻力也是很大的。
如何有效的，快速、低成本、低錯誤率地完成基礎資料準備：
A、確定工作範圍
B、建立必要的編碼原則
ERP軟體對資料的管理是通過編碼實現的，編碼可以對資料進行唯一的標識，並且貫穿以後的查詢和應用，建立編碼原則是為了使後面的工作有一個可以遵循的原則，也為龐雜的資料確定了資料庫可以識別的唯一標識方法，所謂磨刀不誤砍柴工，大家切不可急於求成，忽略了這些重要的工作。
C、建立公用資訊
建立的公用資訊包括公司、子公司、工廠、倉庫、部門、員工資訊、貨幣程式碼等基本資訊。這些資料會在其他基礎資料中被引用，並且資料量不大，可以利用較少的時間和人力完成。如果整理其他資料的時候發現缺少公用資訊再補的話，整體效率和進度會大打折扣。
D、BOM結構的確定
這裡首先應該明確原料到半成品、半成品到產品的級次關係，這步工作的難點是半成品設定的問題。如果半成品設定層次少或層次不設定，今後的統計分析就不能細化；如果半成品設定多，就會大大增加資料量。如果遇到下列情況，那麼半成品要設定編碼管理：對半成品建立庫存賬、或者採用安全庫存管理、半成品對外銷售或用於售後服務，除此以外半成品儘量不用編碼，也不用錄入軟體系統，BOM每多一層，相應增加BOM資料量的同時還會增加物料資訊的資料量，我個人的觀點是儘量少的BOM階次可以使這項工作處於可控狀態。
E、收集第一手資料，將原來的離散資料從不同部門集中
F、資料檢查
（1）完整性檢查：完整性即記錄數量是否完整。可以請企業中有經驗的人員複查或計算一下總數，將其和歷史資料比較。同時還要檢查欄位的完整性，所有的ERP軟體都有必須輸入的欄位，如果缺少這些欄位就會造成系統的不穩定，如物料的提前期、預設倉庫等。另外還有一些非軟體要求的必須輸入的欄位，對企業今後的業務和統計分析有用的欄位也要列入檢查範圍，例如客戶分類和所屬地區等。
（2）正確性檢查：正確性的範圍很廣，可以由公司自己根據需要制定檢查原則。有些錯誤如會計科目是資產型別的，但是因為人為錯誤輸入成負債型別的，再比如有的物料是採購來的，但是錄入成自制件，這樣的錯誤在系統上線前必須發現並改正。
（3）唯一性檢查 ：資料的唯一性應該從兩個角度檢查，常見錯誤有多個實物編成同一個編碼，如果以後錄入系統，成熟的ERP軟體會提示編碼已經存在，並拒絕接受。同時一個實物對應多個編碼的現象也必須杜絕，這種錯誤ERP軟體是發現不了的，必須利用人工查詢，否則在上線後會發生多個賬務錯誤。
G、將資料錄入軟體系統
H、系統檢核