1.ERP實施顧問是做什麽的？
ERP實施顧問？是以公司ERP實施為己任，投入大量人力財力來實現這壹目標的集團嗎？。他們精通ERP理論和ERP軟件的使用，熟練運用項目實施方法論，能夠有效處理實施過程中的各種問題。他們是企業管理方面的專家，很多人在不同行業實施不同的ERP項目都有豐富的經驗，在項目實施的各個階段都能得心應手。
ERP實施顧問？負責項目實施的各個階段，確保在規定的時間內，按照要求的質量水平完成要求的操作，確保必須參與的人員能夠真正高效的參與。為了實現自己的承諾，他們應該把自己掌握的技能和方法轉化為實際的工作計劃？方法要細化到任務，落實到具體個人。還應確定每個階段和任務的時間表，以便最終確定項目計劃。顧問為項目帶來額外的價值，他們的實踐經驗讓公司受益匪淺。他們知道什麽該做，什麽不該做，從而避免？壹個錯誤？正確嗎？如何實施？。
有人這樣總結ERP咨詢和實施的內容？即實施顧問的工作:
1.根據企業內外部環境和資源，分析企業建立ERP系統的可行性，科學制定ERP項目的戰略目標；
2.確定企業對ERP的需求，包括功能、時間和效率的要求；
3.分析企業管理現狀與實施的ERP系統之間的差距，制定企業流程再造和管理改進計劃。在實施過程中，顧問要對企業管理進行診斷，找出差距，提出業務流程再造方案、管理業務標準和數據準備方案；由企業具體實施。
4.咨詢培訓。ERP項目的實施不僅需要管理者知識和能力的提高，還需要管理者態度和行為的改變。然後呢。態度？、?知識？、?能力？、?行動？應該通過培訓執行顧問來促進這壹點。
作為ERP實施顧問，除了要了解管理、ERP軟件、實施方法論，還要掌握壹些做事的方法。好的工作方法可以幫助咨詢師獲得客戶的信任，在項目過程中快速解決問題。
二、ERP實施咨詢工作應努力做好
1.建立和分享信譽。
準確定位自己，積極樹立自己的公信力。從兩個角度考慮問題:壹是從高層管理者的角度思考行業競爭和公司運營，二是從專業細致的角度思考文檔、報表、接口等數據處理。當妳在這些問題上充分展現了自己的專業水準，發揮了自己的作用，妳的名聲自然就建立起來了。
同時要註意與客戶共享信譽。建立信譽的目的是為了更好更快的完成任務，而不是和客戶爭奪項目控制權，比較誰對項目的貢獻更大，誰更優秀。因此，不要把榮譽據為己有，但與客戶端的同事分享榮譽可以建立信譽。
2.建立客戶信心
即使之前有過合作或接觸，甚至客戶因為妳簽了單，在ERP項目開始的時候，客戶也會重新檢查妳的信心和能力，確保他們選擇妳是正確的。所以每次和客戶見面都要做好充分的準備，表現出足夠的敏捷和熱情。主動與客戶溝通，對樹立信心很有幫助。同時，在項目之初設定壹些簡單的目標，然後及時高效的完成，可以讓客戶更快的信任妳。在項目早期建立信心的非常有效的方法是什麽？快速而成功地實現某些結果，或提供額外的價值。
3.為客戶增加價值。
努力超越客戶的期望，為客戶增加價值。我不提倡為客戶提供免費服務，但我建議妳通過合理的工作或可能超出妳承諾的幫助，為客戶提供額外的利益。最好是對客戶非常有價值，又不增加妳工作量的內容。比如和客戶的項目經理壹起完成項目計劃的時候，順便幫助他更深入的了解項目；或者，培訓時提供壹些行業參考資料。
4.有效管理時間
時間是公司的商品，是ERP實施顧問的財產。時間也是世界上最稀缺的資源，所以必須有效管理。這需要兩個最重要的技能:
(1)確定工作的優先級，然後按照建立的優先級工作；(2)為當前既定的工作分配足夠的時間。
5.激發顧客思考
多讀多問，啟發客戶自己思考。
談了這麽久，寫了這麽長的文件，客戶充耳不聞，看了卻沒看到。為什麽？當客戶沒有註意到問題，開動腦筋思考的時候，鴨餡？很難。如果妳先詢問客戶的意見，了解他們對這個問題的看法，妳可以做得更好。不要急著告訴他？正確答案？客戶真正開始思考的時候，會追著妳要答案。
6.鼓勵想法的表達。
當人們開始冥想時，妳應該考慮反饋。如何知道自己對問題的看法？妳知道，不是每個人都願意冒這個險？傻？、?不現實？分享他們觀點的風險。還是要提問通過？什麽？擊球手出局了嗎開頭用開放式問題來拓展客戶的思維，然後用方向性問題來鎖定答案？是嗎？測試妳對開放式問題所引導的信息的理解。
註意，提問壹定要真誠，只要回答了就要感恩。壹旦不經意間對答案表現出輕視，就相當於堵住了客戶的嘴。另壹個值得註意的技巧是:無論答案正確與否，妳的沈默都可以鼓勵客戶繼續深入談論這個話題。
7、把握建議方式
在給客戶提建議的時候，壹定要用恰當的方式，不要讓客戶覺得妳傲慢或者多管閑事。方法是否得當，將決定ERP項目在這個環節的效果(至少是效率)。以下建議可能對妳有所幫助:
？在展示相關建議之前得到對方的反饋是非常有價值的。在這種情況下，妳不必用壹種有希望的方式來表達提議:比如？我們確定的建議計劃是什麽？。？還是，？在另壹個客戶的項目中，我們提出了這樣的建議。與他人討論妳的想法也會提供有用的信息，可以幫助妳整理或修改妳的建議。？
註意？在壹個組織裏，很多人都有發言權？沒有嗎？。雖然他們中的壹些人沒有實權，但他們可以阻止局勢的進展。所以，請記住，妳不僅要說服那些能讓事情發生的人，也要說服那些能拒絕建議的人。？
8.用經驗說話
在ERP項目實施過程中，實施顧問和客戶之間可能有相當多的問題無法達成？合得來？。客戶可能對時間表、人員安排、培訓方法、編碼系統等有疑問。最好的解惑方式就是用經驗說話，讓客戶知道對於這個行業和規模的常規軟件和企業來說，什麽才是最好的方式。註意妳和客戶的實力對比:妳的建議已經被(很多)事實證明，妳的客戶怎麽看？這只是壹個想法！
？妳心裏壹定要清楚，ERP對於客戶來說是壹個全新的領域，客戶在面對這樣壹個昂貴且有風險的方案時，希望得到某種保障。讓客戶知道妳的建議在其他客戶的計劃中得到了很好的落實，可以增加妳的建議的分量。？
9.積極宣傳好消息
聽說過嗎？好事不出門，壞事傳千裏？真的嗎？方法9和10就是為了解決這個問題。
每壹個成功的消息不僅僅是負責？告知？然後呢。慶祝？妳必須用它來堅定大家的信心，讓每壹個好消息都成為下壹階段任務的動力和號角。如何讓好消息傳千裏？當然可以通過正式會議、階段進度檢查、項目簡報等方式進行溝通。，但也可以在與ERP項目組成員或企業中其他有影響力的員工聊天時交流？管他呢。說清楚。
實施顧問應仔細規劃信息的傳輸方式，並通過各種渠道確保其正確性。最近怎麽樣？有什麽效果？等類似問題傳達壹個滿意的答案。在這壹點上，顧問和客戶的項目團隊的利益是完全壹致的。客戶也希望同事知道、理解並相信項目進展順利。希望大家認為項目組做的是有意義、有成果的事情。
10，積極應對壞消息
當不好的事情不可避免地發生時，實施顧問要做的第壹件事就是分析問題的重要性。如果能通過自己的努力彌補，最好不要打擾客戶。悄悄進村，不想拍？，以免削弱ERP項目支持者的信心。如果問題沒有那麽簡單，那麽？最好在問題變成危機之前告訴客戶。最理想的情況是親自去見客戶，並且明確陳述所有相關問題，提出妳的解決方案？。壹般來說，ERP項目組的成員不管怎麽抱怨，都會盡量減少和妳的影響，取得其他同事的信任。
所以壞消息的暗示是基於重要性的判斷。小問題擋住消息，不要讓它發展成壞消息。不應阻止的消息應在項目團隊內部充分溝通，以將影響降至最低。
11，快速解決問題
無論是實施顧問還是客戶，在對ERP的理解、項目進度和資源調度、個人性格和工作習慣、相互信任和工作配合等方面，都難免會出現壹些偏差。畢竟人無完人，事物也不是壹成不變的。壹旦項目和項目團隊出現偏差，就要積極處理問題，這是考驗專家的關鍵標準之壹，也是處理客戶關系的關鍵方式之壹。有些專家(大多是沒有經驗的顧問)不願意承認有他們解決不了的問題，但最好在問題惡化成危機之前承認，並向客戶或公司其他人尋求幫助。
三、ERP顧問工作需要註意什麽？
1，不要輕易告訴客戶？沒有嗎？
當客戶提出問題時，咨詢師要判斷是否屬於咨詢師的實施。如果屬於顧問執行，自己不清楚，就要把問題記錄下來，跟客戶解釋清楚，回去咨詢資深顧問給予解答。如果問題不屬於erp範疇，比如客戶問erp系統是否可以根據mrp的能力自動安排訂單和車間的計劃，其實是不可能的，這屬於人工智能。這個時候，他應該向客戶解釋清楚。
2.永遠不要貶低別人。
作為壹名ERP實施顧問，批評和指責妳的同事、客戶和競爭對手對妳的聲譽沒有任何幫助。妳不能在任何人面前給那些過度投入的銷售代表，總是有bug的開發人員，以及其他沒有完成任務的實施顧問看？無奈？、?抱怨？討厭？。如果客戶對妳同事的抱怨是合理的，或者妳對妳同事的問題感到憤怒，妳絕對不能置身事外。妳應該也只能先承認，然後及時處理投訴，而不是貶低同事，哪怕是附和。
3.通訊技能
註意自己的形象和肢體語言。顧客說話的時候要註意對方。不要搶話，做出壹些不好的舉動。
開始談壹個項目的時候，要了解對方公司的行業特點，以及談判人員在企業中的職位和學歷。當我們覺得對方的管理知識和實踐經驗超過自己的時候，要謙虛，關鍵時刻發表壹些看法，把話題引到軟件上來。當我們覺得對方的管理知識不如自己的時候，要和對方談管理問題，談解決問題的軟件，不要談系統解決不了的事情。
4.不追求理論？完美？
來定義任務？我們需要的是簡單可行的解決方案，而不是理論上的？完美？。
5.管理問題
由於管理混亂，數據收集不及時。這時候實施顧問可以提出壹些管理方案，具體的實施顧問不要參與，企業自己實施。
分類:ERP理論和實施方法
我已經實施了幾個ORACLE HRMS項目，因此在我自己的實施過程中分享壹些經驗和想法可能不太系統:
總體:1。制度的實施是要和人打交道的，尤其是人力資源制度。和他們搞好關系是必要的，也是必然的？制度好不好，能不能用，都是人做的，人說的。作為信息工具和數據倉庫，大量基礎數據的錄入和維護都是人工完成的，必須要有他們的支持和配合。2、不懂需求，人力資源管理，哪個單位都差不多，從技術角度來說，也就是說只要妳跟著壹個項目的實施，就壹定能獨立做另壹個項目。妳不用擔心這個。至於業務，大企業小企業國企外資都不太多，就是報表和管理側重於內容和精細度的區別。對現有業務規則和總體目標的大致理解是差不多的？要意識到。3.系統真正開始實施階段，詳細制定計劃。計劃越詳細，工作就越容易，然後就會壹步壹步地進行。當然，周密的計劃也意味著調整計劃的可能性越大，只要控制在整體進度範圍內，抓住重點即可。不需要因為壹些可有可無、輕的流程或步驟而頻繁催促用戶。畢竟大家都要互相體諒。我做的壹些項目有嚴格的過程控制。其實系統的實現是為了用戶，壹定要把握好這個終極目標。至於文檔和UAT測試，掌握得差不多了。妳不會真的指望用戶在UAT期間為妳測試系統的功能、安全性和穩定性吧？需求分析階段:4。根據妳所有的知識，包括業務知識和系統功能，盡可能的列出需求清單，把要問的問題文檔化。要求要詳細，問題要問到位。妳可以通過調查結果在它們之間進行選擇。對於大型企業和集團企業，要參考公司層面的意見。但更需要采訪基層單位的具體業務人員。畢竟系統主要是他們用的，ORACLE本身的可操作性有壹定的局限性。多和他們溝通，有助於消除這個系統是為群體服務的觀點。有時候大型項目，基層用戶多，不能簡單填寫。要找壹些業務精通的人，面對面的，壹個壹個的溝通。此外，他們對壹些問題的看法也需要系統地解決。對於集團來說，他們更關心報表，他們需要那套人員指標。他們只是給出了大致的框架和目標，並不能挖掘出更多的東西。具體的事情還是由下面的人來做。另外，在需求分析階段，往往會有系統原型的演示。無論妳如何準備這個演示，都會更糟糕，業務人員會發生沖突。這壹點與關鍵業務人員溝通更為重要。這個階段不是討論系統是什麽樣子的，而是討論未來的業務應該如何實現。不要陷入對系統界面、壹些特殊功能、員工編碼等不能馬上解決的無聊問題的爭吵中。求解階段:5。整理好需求分析後，就可以考慮解決方案了。那就是未來如何實現系統。對於人力資源來說，應該是比較簡單的。但也要慎重考慮需求的選擇。有些需求是矛盾的，有些需求是現有的工作模式。ORACLE標準函數中有更好的替代方案，有些是合理的，但ORACLE標準函數無法實現。這些都要跟人力資源部的人好好解釋，最後得到用戶的確認。不要忙著完成這個文檔，這對於文檔本身很重要，但也是最值得持續討論和改進的。不要以為按照這個文檔配置系統就可以是壹項工作。在用戶實際使用這個系統之前，有很多變數。早改不如晚改。所以要根據自己對業務和系統的理解，認真給用戶講解。怎麽做？妳為什麽這麽做？優先考慮可擴展性，讓用戶覺得妳是真的在為他們考慮問題，而不是基於上壹個項目的經驗去嘗試自己創業。這個比較關鍵。只有在完全理解* * *的情況下，才能將本文件交付簽字確認。系統配置階段:6。相信甲骨文，沒有甲骨文HRMS做不到的，只有妳不會做的，或者暫時不會做的。最多就是繞道而已。不要聽甲骨文銷售人員或者技術支持人員或者PPT介紹的概念。只要能使用的功能或者有價值的功能，妳都可以自己測試壹下，知道裏面有什麽，實現的時候能做什麽。甲骨文是強大而開放的。所以，我不怕做不到，只關心怎麽做。不要怕定制。沒有定制，甲骨文玩不了任何項目，但是每壹個定制都要認真論證。是否合理高效？客戶認同嗎？有沒有推廣價值，未來拓展如何？對於定制化開發，其實壹個有經驗的顧問在前兩個階段就已經胸有成竹了，不要在這個時候感嘆定制化這麽多。ORACLE本身的標準功能是有限的。不要害怕。它需要定制。多和客戶溝通，讓他們知道妳為他們做了很多工作。很多公司嚴格控制定制，這個是改不了的，還是不要動的好。其實我不太贊同這種方式。該系統是為用戶操作的。升級，版本控制，技術轉移都很麻煩，因為妳沒有做好。這要比優化壹個操作，讓幾個甚至幾百個業務人員每次輸入工資數據時少按壹次Enter鍵容易得多。不要把別人的工作量誤認為工作量？對商業人士的尊重也會得到同樣的反饋。當然也不是說什麽都是定制的。這不是壹個甲骨文HRMS系統。懂得識別壹些不合理的需求，與用戶溝通，獲得用戶的理解和支持。定制主要寫在上面。至於標準函數，基本都是值集，彈性域，菜單之類的，就不多描述了。總的來說，仔細考慮擴展性、方便性和安全性，不要因為自己的武斷造成後面的重復；做妳能想到的，不知道可能有問題，等用戶提了再調整。系統測試階段:7。仔細測試壹下。標準函數沒有問題。定制需謹慎。如果沒有人力，找重點用戶也是可以的。不要等UAT。當UAT完成後，它將正式推出。到時候，又會有新的問題等著妳去處理。妳寧願紮實地做好這部分工作，把時間留給用戶培訓。數據采集階段:8。這通常與系統配置和系統測試並行。不放松？花在數據收集上的時間永遠是最長的，也是最煩人的。壹個好的數據收集模板至關重要。另外，對於舊系統導出的數據，即使原系統數據完整，也要考慮數據進入新系統後的合法性。首先設置員工編號，而不是序列號。不要太相信用戶的身份證號，尤其是來源不壹樣的，比如人事、工資，我從來沒見過完全壹樣的。檢查壹定要太細致，前期做好工作總比後期頻繁打斷關鍵用戶的工作好。另外，在數據核對和後續導入中，擅自更改用戶數據太麻煩。至少，先記錄下來，讓他們確認後再導入系統。運維支持階段:9: Oracle HR加入生效日期新概念。而且機構、人員類型、薪酬、解除聘用都是壹體化的，不是接受能力強的用戶。如果妳自己做，妳肯定會犯壹些錯誤。剛開始的時候，妳會經常去找用戶，問更多的問題。不要光上網就萬事大吉了:)我還沒拿到錢。另外，人力資源項目不是壹下子就能完成的，後續的培訓、能力、績效都比較麻煩，沒有統壹的標準。維護好用戶關系就是維護好妳的工作:)希望大家完成壹個項目後能交到朋友？10:還有壹個訓練階段，這裏暫時不贅述；