第一篇：一個ERP項目經理的一些實施體會

一個項目經理的一些個人體會

本人做項目經理工作多年，感到做這個工作最要緊的就是要明白什么是因地制宜、因勢利導，只有最合適的，沒有什么叫對的，什么叫錯的，項目經理最忌諱的就是完美主義傾向，尤其是做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。以下是本人一些做項目的個人體會，寫出來供大家指點，在討論過程中共同提高水平。

項目開始階段是一個最重要的階段。項目經理在接手一個新項目的時候，首先要盡可能地多從各個方面了解項目的情況，如：

1.這個項目是什么項目，具體大概做什么事情，是誰提出來的，目的是解決什么問題。在國內很多客戶都很不成熟的情況下，千萬不要根據項目的名稱望文生義地去想象項目的目標。一個名為“辦公自動化”的項目很有可能在你進場以后一個月才發現客戶其實需要的是一個計算機生產管理輔助信息系統系統。前期了解情況的工作越詳細，后面的驚訝就越少，項目的風險就越小。.這個項目里牽涉哪些方面的人，如投資方、具體業務干系方、項目建成后的運營方、技術監督方等等，很多項目里除了業主單位的結構很復雜以外，還有一些其他單位也會牽涉進來，如項目監理公司、業主的行業主管機構等。項目經理需要了解每個方面的人對這個項目的看法和期望是什么。事先了解各個方面的看法和期望，可以讓你在做項目碰到問題的時候，就每件事情分析哪些人會在什么方面支持你，哪些人會出于什么目的反對你，從而提前準備聯合朋友去對抗敵人，讓事情向你所希望的方向發展。沒有永遠的朋友，也沒有永遠的敵人，只有一致的利益，這句話作為項目經理是一定要記住的；

3.基本了解了客戶的情況后，下面的事情就是了解自己公司各方面對這個項目的看法。首先是高層領導是否重視，這個決定了你在需要資源的時候，公司是否會根據你的要求提供最有力的支持。領導口頭肯定是說支持的，你需要做的是了解公司對這個項目的實際期望，是想把項目越做越大還是想賺錢？是想做樣板工程還是干脆想敷衍了事，公司領導對項目的態度決定了你做這個項目的戰略，而這個戰略方針將對你做項目計劃產生直接的影響；

4.在做整體項目計劃前，還要大致計算一下你手上的資源。首先是時間，現在市場競爭激烈，往往很多項目要求在幾乎不可能的時間范圍里完成。對于這一點，你在做項目的風險控制計劃的時候要充分考慮。其次是人員，根據項目預算和已往經驗，大致計算一下未來的項目小組有多少種角色，每個角色目前公司是否有人，是否能完全歸這個項目使用，是否需要另外招聘一些人員，招聘的準備工作要盡早

啟動。最后就是一些設備的準備，項目所需大件關鍵設備要盡早預定，以后不管發生設備等人還是人等設備的情況，浪費的都是你的時間；

5.現在是做項目說明書的時候了。一份好的項目說明書不僅將要做的事情描述得很清楚（主要是講做什么，而不是說怎么做），而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情，也讓客戶的業務人員（一般不懂技術）知道項目做成什么樣就算完成了。簡單地說，項目說明書描述項目做哪些事情和每件事情做到什么程度以及如何檢查每一個結果。

6.是到做總體計劃的時間了嗎？不，你現在已經知道了客戶的目標和你手上的資源，那么做計劃以前，你還需要和你的經理和客戶充分溝通資源的問題。因為很多資源是還不明確的，你需要寫一份報告，詳細分析這個項目的風險以及對資源的需求情況。如果一些問題不能得到解決的話，將發生什么樣的后果。如果資源不夠，就要高層改變策略，增加對這個項目的投入。甚至在條件許可的情況下，有些公司會放棄這個項目。總之，沒有人能完成一個不可能完成的任務，如果項目經理不能盡早發現風險，那么就只能去當烈士了。

7.明白了要做哪些事情和你手上的籌碼以及你做這個項目的總體策略，現在是成立項目小組的時候了。很多項目經理都沒有自己選擇組員的權利，那么，就盡量發揮你的影響力去尋找那些你想要的人吧。成員的組成根據項目不同，相差較大，很難有什么具體要求，但是，一定要有精通客戶業務的人，很多小項目里，這個人就是項目經理本人，大項目里會配備行業專家（Industry expert），這樣和客戶溝通起來才不會雞同鴨講，雙方才可以相互理解。我經常看到的情況是我們的技術人員和客戶交談時滿口的專業術語，結果搞得客戶一頭霧水，反過來，他還指責客戶不懂技術。其實，明白自己想做什么的客戶已經是很好的客戶了，不知道自己要做什么，更不懂怎么做還要指手畫腳的客戶到處存在，但是要明白，是客戶選擇了你，而不是你選擇了客戶，有了客戶你才有工資拿，心平氣和一點吧；

8.現在你要面對三群人：你的領導、你的組員和你的客戶，和這些人溝通，讓他們知道你打算怎么做，什么時候要他們做什么準備這些事情將是你的主要工作。既然溝通這么重要，那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則都是潛規則，如果你在一個部門時間做長了，對這些規則的運用覺得是一件理所應當的事情，但是，你現在面對的是多個部門甚至多個單位，不把溝通規則說清楚，你以后就會吃虧。下面的東西看起來無聊，其實還是很管用的：第一個是規定信息的流動方式和介質，是推還是拉。推的意思就是項目經理將主動發布信息，不管通過電話、郵件還是書面方式，保證將信息傳達到每個人。這種情況適合小項目，人少；拉的意思就是項目經理就是一個類似web服務器，你自己需要什么信息就去問他。當然，沒有項目經理把自己搞得那么累，他會用發布信息到公共介質的

方式公布信息，簡單的是白板，復雜一點的是項目的公共信息交互區，潛規則就是我發了你沒去看就不要說我沒告訴你。說這些看似很無聊，其實里面牽涉信息傳達不完全的責任問題。當然，這些都是指一般的方式，而且不要絕對化，一般情況下，主動溝通和被動訪問是同時存在的，尤其是對領導，項目經理更加應該主動去和領導溝通。第二個問題就是文檔問題，很多人怕寫文檔，但是項目經理一定要牢記“好記性不如爛筆頭”的道理。有理有時候為什么會說不清呢？就是因為沒有證據。所以項目經理開始就要和客戶說清楚有些文檔是必須簽字的，比如項目經理的項目日志，每個星期至少讓客戶簽字，另外所有達成共識的東西，比如會議紀要，甚至領導的講話記錄，都要寫成文檔，雙方簽字，這樣以后扯皮的時候，就能做到有據可查。記住：說了的就和沒說一樣，只有寫下來大家簽字后才算真正發生了的。還有一些問題，比如你提交的報告，給領導（包括本方領導和客戶領導）做一個選擇題，結果領導壓住不批，讓你無所適從，結果拖延了進度。這時候，你可以等，但是注意要留記錄，標明是誰的責任；另外，如果你在開始階段就和領導商定：如果批示提交三天后沒有得到領導答復就算對方同意，這樣你就會主動很多。再比如不同事件的審批流程問題：什么等級的事情記錄在項目日志里、什么等級的事情要雙方項目經理專門簽署備忘錄、什么等級的事情要雙方領導出面簽署合同附件等等。事先想得越周到，以后的工作就越主動。

9.好了，做了很多前期工作，定義了一些游戲規則，現在是坐下來做計劃的時候了。這一節，任意找一本項目管理的書都會說得比我好，所以我就少寫一點，說一些自己的體會就是了。首先是找幾個關鍵組員，比如客戶業務專家、系統分析員等等，做一下項目模塊劃分工作。項目分成幾塊去做，每一塊完成什么，模塊之間的信息如何交換等等。需求定義的是做什么的問題，而這里說的是怎么做的問題。這里要強調一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的，這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動，堅持要你采用那種新技術，你就應該告訴他：你選我做這個項目，就應該容許我采用自己最喜歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成為第一批受害者。采用一個計劃會讓你的工作更加明確，比如用微軟的Project軟件，你填寫完表格以后，就可以知道這個項目有多少件事情要做，每件事情需要什么資源，他們之間的前后關系如何，消耗的時間有多長，完成后有什么標志等。所有的結果最后用一個叫做甘特圖的形式表現出來。你做完這個表以后會驚奇地發現，甘特圖上項目的結束時間會遠遠落后于你的計劃結束時間（簽合同的人永遠不會先征求你的意見的）。當然，學過項目管理的人會大談什么WBS、優化路徑之類的東西，但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜你挑了一個輕松活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候，你就要考慮犧牲一些任務的時間（也意味著質量）了。按照什么標準犧牲？這個項目的戰略！我們在第三節提到過的戰略。我的經驗是如果你什么都趕進度，其結果

可能就是十件事情你一件也沒做好，想想多么失敗啊。所以，把資源投到你熟悉和有把握的事情上，最后的結果是十件事情，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了很多呢？戰略決定優先級，而正確排列事情的優先級是一個項目經理能力的主要體現。

好，現在項目已經完成了前期工作，了解了項目的目標、搞清楚了手上的資源，制定了項目的策略，然后編制了項目的整體計劃，項目進入實施階段。進入這個階段反而是項目經理比較空閑的時候，不像前期的時候項目經理要象記者一樣到處和不同的人接觸，搞清楚他們在說什么，努力猜測他們在想什么和他們的真正目的，那才是最累人的事情。當然，小項目的項目經理往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。項目經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意，除非你需要對方給你支持，那么你才需要講得具體一點，否則，告訴他一切正常就可以了，而且態度要積極一些，千萬不要說一些領導不懂的細節，比如：“王局長，最近項目進度還算正常，就是JVM經常發生一些內存泄漏的情況…”王局長：“(*&$@@”。和自己的領導匯報也要注意這個問題，除非他是一個技術高手，你需要他的技術經驗，否則一般就匯報進度是否正常以及有問題時你的對策和打算就可以了，有些需要他支持的地方，比如資源調用需要說詳細一點。

和組員開會，除了一些項目進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強（如果總結得不對，歡迎大家拍磚），所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現象是完全不同的，想想盲人摸象的故事吧。這些技術人員，他們往往精通一個方面，就自己的角度發表見解，除非一些很特別的情況，你都應該認為，他們提出的方案，從他們的角度來看是最合理的。你的長處是掌握事情的優先級，評估各個方面的輕重緩急，從而根據他們的意見得出一個合適的（而不是正確的）方案。所以，在會議上，你要充分尊重每一個人和他的意見，夸獎那些意見提得比較好的人，千萬不要把會議帶入無休止的爭論（你要讓大家知道事情不是非黑即白的，而是多元的，唉，我們的教育惹的禍…）。會后，你自己寫文檔，做決定。會議上大家的面子都被照顧了，自然實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能說服他，你就要讓他明白，因為你負責這個項目、你擔當風險，所以，這個優先級應該你來判斷。組織中的高層，并不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之信息的不對稱性，所以，對事情的優先級的判斷肯定比下屬強。

在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組布置任務的時候就要考慮如何檢查結果，比如我見過一個計劃，里面有一個任務

【開發人員熟悉EJB編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情，我聽說有些老項目經理拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然后決定工作計劃。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那么多勞動后得到結果。另外我插一句：我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流，很容易引起沖突和矛盾（技術人員的本性決定的）。我的做法是項目經理和項目實施人員到現場，軟件開發人員還是在公司做項目。項目實施人員就是初級項目經理，他們了解自己的產品，懂得一些客戶的業務，關鍵是在于他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發人員的橋梁，其職業方向也是很機動靈活，以后可以有很多方向可以轉，比開發人員的路要寬得多。

接著，我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更；另一種是沒改變目標，但是客戶不滿意目前的實現方式，大到流程的實現，小到界面的布局，都是屬于這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改并且你的戰略是容許這種情況的，那么注意下面幾點：

1.確保以前的文檔，就是記載著以前的結論的東西，客戶是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客戶自己確認一下你的方案，然后讓他簽字，避免以后說話沒有憑據；

2.和客戶坐下來，自己探討他修改的根本目的是什么，是不是有同樣能達到相同目的，但是對你來說有代價更小的選擇？

3.（項目初期的工作）明確更改流程，一般是客戶指定一人簽字（否則客戶每個領導都有權力來插一杠子，你就廢了），以正式項目文件的方式提交給你，然后，你做評估分析，分析對成本、進度的影響，在你的領導同意后，出相應意見書，主要是要說明更改設計的原因和指出由此帶來的不確定后果（這個東西先寫出來，后面如果真的發生了，至少不是你的錯）。然后再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人簽的免責條款嗎？對，就學習那個，讓大家都意識到任何的更改都有成本和代價。

系統開發告一段落后，就進入客戶培訓、系統驗收階段，這個階段，我一般會注意以下幾個問題：

一、給客戶做培訓前，多注意一些表面功夫。很多程序員認為，既然很多系統采用原型法，有一個由粗到精的過程，那么系統的邏輯核心是否正確才是關鍵，至于界面如何，界面上的用詞是否準確，那是無關緊要的問題；而且培訓的時候也是空手上臺、信手拈來，想到哪里說到哪里，下面聽講的人不知所云，云山霧罩，培訓效果自然可以想象。我的體會是，給客戶做培訓的版本，如果你在做多次測試以

后仍然不能確定邏輯是否合乎要求，那么，你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、鏈接的正確性等等，總之不要讓客戶看到一些他不該看到的東西，否則，僅僅因為一些無關緊要的報錯就讓客戶第一印象覺得系統不穩定，那你就真的比竇娥還冤了。文檔方面，準備至少兩個文檔：用戶手冊和培訓手冊。這兩個文檔的內容很多都是一致的，但是角度完全不同。用戶手冊往往是站在系統設計者的角度，按照自己的思路，分模塊講解系統的操作和功能；而培訓手冊，一定要站在客戶業務人員的角度，根據每個角色面對不同業務的辦理，如何通過使用本系統的一系列功能來實現目標。所以，第一次培訓以前，系統界面是否完整正確、培訓文檔是否完備、培訓時所舉的例子是否有代表性都是很關鍵的因素，第一炮打不響，以后就麻煩很多。

上面講的是培訓的時候，丑媳婦要化妝好再去見公婆的問題。其實，項目實施中還有一個考驗項目經理功力的就是如何調動客戶積極性的問題。一般來說，客戶是懶的，這就是他花錢找你做事情的原因。一個項目的成敗，和客戶的配合程度很有關系。根據我的分析，一般項目中的客戶都可以分為三類：支持的、消極觀望的、抵觸的。他們人數的分布一般是一個紡錘形：支持的和抵觸的人少，觀望的人多（如果你接了一個人人都抵觸你的項目，那你還是不要做了）。首先，分析一下那些人為什么支持你和抵觸你。很簡單，于公于私兩個方面分析，上了新系統，誰的工作量有所變化？誰的潛在利益是否受到威脅？誰的崗位是不是因為新系統而消失？傳統的利益格局因為新系統的使用而發生怎么樣的變化，這些東西，都是項目經理必須去了解的，這樣，你才能團結那些支持你的人，消減那些抵觸你的人。項目經理是一個很奇怪的角色，屬于典型的責任大、權力小的角色，他能做的只有借力打力，不管在自己公司還是在客戶那里，一定要依靠別人才能完成自己的目的。只有了解哪些人會因為什么而幫助你，哪些人會因為什么而抵觸你，你才能讓客戶配合你做工作。比如上一些內部計算機輔助管理系統，其必然后果就是讓本來管理混亂時有人可以渾水摸魚的一些利益消失掉了，這樣，有些人肯定就要搗亂，到處詆毀這個系統。這時候，你就可以散布一些“誰抵制新系統就說明自己屁股上有屎”這類的論調去壓制他們，減弱他們的影響。

作為項目經理，其實腦子里就是幾樣東西：做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優先級。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬于典型的又要馬兒跑，又要馬兒不吃草的類型?？紤]問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你最后期限，所以保進度是第一位的；省是第二位的，企業的根本目的是盈利，如果收入不能增加的話，至少費用要控制住；好是第三位的，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質量只好先犧牲了；最后是多，客戶的要求源源不斷，如何降低客戶的期望值，讓他們從理想回到現實也是項目經理的分內工作。

驗收前，除了做好文檔工作，即可交付成果以外，多花時間搞清楚客戶的做事情流程是很重要的事情，這些在前面已經有所提及，這里就不再多說。

我對驗收最大的體會就是舉證問題。即千萬不要讓客戶這么想：你必須有證據證明你的系統是沒問題的。這樣你就沒戲了，微軟那么多天才，做了XP還天天打補丁，要你的程序沒問題，既不可能，你也沒辦法拿出證據。你要讓客戶明白，所謂驗收，就是我按照測試文檔的測試用例跑一遍，結果和預期結果一致就應該算通過了，而且還容許有一些小錯誤留在驗收后改正，他可以對測試用例提意見。所以，驗收前雙方要確認測試計劃和測試用例。如果他認為系統不符合要求，那么他應該舉證，證明這個系統和最初設計相背離的。所以，參考法律概念，千萬不要舉證倒置。另外，認為系統完美了才能驗收的想法也是錯誤的，軟件開發合同里一定要注明驗收以后維護期的費用問題，否則，客戶擔心一旦驗收就得不到你們的支持，自然不配合驗收，那么，你這個項目經理就很難交功課了。

第二篇：ERP實施項目經理崗位職責

ERP實施項目經理崗位職責5篇

1、擔任項目經理，主導大項目的實施，達成項目預定目標;

2、主導或協調資源，進行項目的業務調研、診斷、分析，形成滿足客戶需求的業務解決方案;

3、分配團隊成員工作任務，輔導團隊成員完成項目工作任務，把控任務質量

4、知識沉淀與分享，及時沉淀業務中發現的價值要點;

5、針對軟件產品的銷售，提供售前支持;

ERP實施項目經理崗位職責(二)

1、負責ERP項目實施、用戶培訓、現場運行指導及硬件網絡的維護使用;

2、收集并編寫客戶需求，制定客戶企業規劃流程;

3、項目進度的跟進，項目驗收的跟進;

4、協助開發人員完成開發，測試，培訓，技術支持與開發需求調研;

ERP實施項目經理崗位職責(三)

1、作為項目的第一負責人帶領團隊實施交付項目;

2、制定合理的項目計劃，有效掌控項目實施開發的各個環節，協助、指導項目組成員的工作，及時發現并處理項目中存在的問題;

3、負責管理和控制項目全過程的質量、進度。分析偏差，采取糾正措施。如果發現項目實際進展顯著偏離計劃，則及時采取糾正措施;

4、組織進行需求分析、藍圖規劃設計、上線指導等工作;

5、負責項目過程的文檔管理;

ERP實施項目經理崗位職責(四)

1、負責ERP項目的實施支持和項目管理工作;

2、能總結提煉優秀企業的管理模式，參與實施標準化建設;

3、有能力組織一線顧問項目團隊的能力提升。

ERP實施項目經理崗位職責(五)

1、負責ERP項目的實施項目管理;

2、制定交付策略和交付計劃，控制項目過程，帶領團隊確保項目按時、按質、按量完成，實現各項項目目標;

3、主導完成大型復雜項目風險控制和交付;

4、總結提煉優秀企業的管理模式，制定和完善項目管理體系和方法。

第三篇：一個ERP項目實施工程師的若干體會

本人在多年的工作中，參與了ERP的研發和實施，對ERP有較深的認識。在這里，根據自已的實施過程中的一些經歷，把自已在實踐中的一些體會貢獻出來和大家共享，由于時間和精力所限，內容難免有不當之處，掛一漏萬，僅供參考。

國外關于ERP實施的階段劃分是有道理的，只有在這每一個階段的工作都做好了，才能保證ERP的實施成功?，F在我就結合這個程序來分析一下ERP實施。

1.領導培訓

ERP系統被視為一把手工程，對企業高層的領導的培訓是一項目十分重要的工作。而實際情況是如何做的呢？企業領導一般工作比較繁忙，實施企業也出于成本考慮，相應培訓普遍偏少，對ERP的理念作的導入工作不足，往往影響實施效果。培訓目的是讓他們形成共識，理解為什么ERP系統是管理改造項目，離不開高層領導的支持；另外一個目的就是讓他們對ERP系統有一個正確的預期。如果，不對高層領導進行培訓，他們對系統的認識不清，他們會認為系統不就是一個軟件嗎？沒有必要投入那么多的錢。

2.需求分析

一定要確定好用戶的最終需求。在有的項目，我們認為具體的業務流程我們已經很熟悉了，固然沒有什么具體協商的。但是到了最后使用的時候，我們就發現我們還是對其詳細操作沒有搞清楚，我知道的業務流程僅僅是一個大體上的概念，對于細節的業務我并不清楚，這個問題是我后來在項目延期的主要因素。

確定用戶的最終的需求，根據用戶的需求編制一定的界面，然后根據編制的界面和用戶進行核對，以保證我們表達的和用戶需求的相一致。如果不一致，重新修改我們的界面。

根據和用戶討論關于操作問題，這個階段就是搞清楚用戶的視圖，讓最終用戶直接參與項目的開發，當然他們的作用是提供一些參考改進的意見，這些意見是針對最終用戶的操作，目的是讓操作更加貼近用戶。

3.BPR

在項目的實施過程中，企業管理流程的重組工作往往是最難的。我認為在國企要對企業業務流程作根本性的重組幾乎是不可能的，但一點改進都沒有而要成功地實施ERP同樣幾

乎不可能，實施人員提出過對企業工作流程進行改進的建議，往往泥牛入海，沓無消息。只能根據企業重點控制環節，盡可能多做些改進工作。

4.項目組織

一般要成立了三級項目組織，企業一把手出任領導小組組長，核心小組、各部門項目組也有相應負責人出任組長。業務問題要在項目組織的會上就能解決，切不可流于形式，讓用戶以工作忙為借口，不參加工作。

5.實施計劃

由于ERP涉及面大，計劃的組織工作極為繁重，頭緒極多。項目開始時，不可輕易承諾項目何時完成,一方面，項目剛啟動時，項目的實施范圍通常還比較模糊和抽象、不是很具體。只有等到需求調研以后項目實施范圍才會逐步具體化，即使到這時，項目范圍還存在隨著項目進展發生改變的可能性。

另一方面，如果對客戶承諾了一個固定不變最終期限，如果在調研時客戶發現需求和設想有很大不同，比最初項目評估時要復雜的多，因為完成日期已經無法更改，這樣造成的后果是項目組成員需要投入更多的時間或者匆忙之下只能提交一份不令人滿意的解決方案。

因此，項目經理必須和客戶溝通，使客戶明白，項目完成日期的確定取決于兩個因素：一是需求調研完成以后，雙方共同確認的項目實施范圍；二是要考慮到項目所需資源約束。這樣如果以后項目范圍明顯地超過最初確定的范圍，項目經理就需要和客戶討論，要么讓客戶縮小項目范圍，要么延遲項目完成日期。

在ERP項目實施中，必須制定明確的里程碑，以及每個里程碑應取得的成果。項目經理在項目的開始，就需要讓項目組所有成員知道各個階段的里程碑和目標，以及進度的安排、資源的大體上的分配，就好讓項目組的所有成員參與討論，但項目經理應控制談論的范圍，需要避免在項目初期在實施上的分歧。

大型ERP項目的實施往往時間很長，這樣項目剛開始，項目組成員有一種錯覺，認為時間還很充足。所以必須對里程碑進一步細分，制定短期的實施目標，讓項目組成員時刻保持高效的工作狀態，如果這些小的目標都能按時完成，那么整個項目按期完成就有了保證。

ERP項目實施時間長，對實施者和客戶來說，成功似乎遙遙無期。如果將目標進行分

解，讓實施者和客戶都感覺到一段時間就實現了一個目標，可以激發項目團隊和客戶的積極性。

6.培訓工作

對于用戶，其關鍵用戶和最終用戶的培訓是不同的，但先培訓關鍵用戶，再由關鍵用戶去培訓最終用戶，這樣是有好處的如：

語言上不存在障礙，同樣一個流程或操作，最終用戶一般更容易接受關鍵用戶概念，而我們的概念往往是不能被最終用戶直接接受的，這里面有行業術語上的障礙，在我們表達上基本上是計算機的術語，而用戶所能接受的是他們行業上的術語。

更容易組織，由于我們是外部人事，對于他們我們基本上沒有什么威懾力，如果有也僅僅是在技術上的敬佩，所以對于企業的協調能力或方式，不能見效，其內容也往往流于形式。

(3)自然培養企業內部技術支持路徑，而比直接詢問我們有更好的效果，這樣也會在我們的市場推廣上有較為“陽光”的一面(就是在向其他用戶推廣時采用用戶本身直接介紹的方式)。同時其最終用戶在詢問關鍵用戶問題時，自己也會很好的考慮。(4)鍛煉關鍵用戶，讓關鍵用戶在培訓別人上對本系統有認識上的提高。

7.數據準備

數據準備的重要性無庸贅言，要各種場合反復強調了基礎數據的重要性，并要求企業采取切實的措施來保證這一點。

在準備數據之前，成員要準備一份“數據準備文檔”，在該文檔中要明確如下內容：數據準備時間，范圍。即何時完成，準備何時的數據，準備哪些數據。

明確雙方責任。我們一般要求客戶來準備基礎數據，并保證數據的完整性、正確性(實際也只有客戶自己才能做完后，才知道數據的真確與否，一定要盯牢客戶完成數據的測試)；項目組只提供數據準備的要求、格式。

數據準備的要求?？蛻舯仨毎凑枕椖拷M要求的格式來準備，這一點非常重要，很有好處：

(1)可以保證數據的完整一致。比如說，要準備供應商資料，我們在Excel中準備好空

白如下表格。針對這個信息我們提供的一個更加詳細的說明方式，讓其自由填寫。但以上表格中的數據是必須填寫的。這樣每個準備供應商信息的人，都知道供應商資料應該包括：供應商名稱、編號、地址、稅號/帳號、聯系人等。

(2)方便核對數據。一旦在Excel中準備好數據，并核對無誤后，就需要輸入系統，輸完以后，再用系統生成并打印報表(但我們沒有這樣做，我們自己準備一個數據庫，在瀏覽器的界面，讓客戶自己直接在瀏覽器的界面填寫，然后提交到數據，這樣就減少了打印重新填寫或導入的步驟，比如，對上述供應商資料，我們可以從系統輸出一份報表，去和原始的數據核對，看看在輸入過程中是否出錯即可)。

(3)如果基礎數據量很大，一般就需要開發專門的數據轉換程序，這樣更需要按一定格式準備數據，否則，數據轉換程序不會正常工作。如果企業本身沒有其他系統(現在一般企業都沒有)，即可讓其直接進行輸入。

在實際工作，很多客戶一開始感到不理解，認為沒有必要一定按照某種格式準備，作為成員一定要和客戶溝通，解釋重要性。

8.二次開發

在市場經濟的調節下，組織變動在公司中是司空見怪的，如果在項目過程中發生的話，其項目內容(人員、系統設置和數據)也必須跟隨著變化，這個變化是很糟糕的。如果變化是頻繁的，所以程序結構和維護流程不停的變更，有時會導致系統實施無期限。

ERP設計本身應是靈活的，對于企業結構有一定的適應力，當然在項目中也應該控制企業的變動。這個問題需要分兩方面來看，首先，ERP系統立意要高，要高到和公司組織結構規劃一致(當然對于企業本身也應該考慮企業重組的問題)。其次，就象人在適應社會的變化以前會經歷襁褓期，但我們也該注意在ERP實施的襁褓期減少不必要的震蕩，使項目成功完成。

9.系統正常運行

上述工作均完成后，我們的系統就是要正式運行了。

1.驗證設置是否正確。比如各種基礎數據輸入后，經檢查，均正確無誤，但系統生成結果就是不正確。這種情況下，我們就需要檢查是否是設置問題。諸如此類的問題很多，需要

一一驗證。

2.制訂各種業務規則。上了系統之后，許多新的業務流程和企業原有的業務流程不同，而最終用戶往往習慣了以前的做法，短期內可能不適應。為了確保系統真正用起來，必須做好以下幾點：

(1)做好培訓工作。培訓系統的操作和系統的業務流程。

(2)制訂詳細的業務規則，規定企業各種業務在系統中是如何處理的。并讓每位相關的最終用戶知道、理解。

(3)制訂必要的制度，確保按規定操作，特別是在使用系統初期，完善制度尤為重要。

第四篇：ERP實施顧問和ERP項目經理的工作區別

ERP實施顧問和ERP項目經理

ERP實施顧問和ERP項目經理在ERP項目中都是常見的項目成員，但是有時候ERP實施顧問也同時擔任ERP項目經理，并且ERP項目經理有時也做一些實施顧問的工作，這讓一些關注ERP領域的新人丈二和尚摸不著頭腦。這里詳細解說下ERP實施顧問和ERP項目經理兩者之間的區別和聯系，以供大家參考，不當之處也請業內高人批評指正。

ERP實施顧問和ERP項目經理是根據項目來定的角色。例如，張某在甲項目中擔任ERP項目的實施顧問，也有可能在乙項目中擔任ERP項目經理。在大型ERP項目實施過程中，是有一個項目實施團隊來進行ERP項目實施工作的，通常一個ERP項目實施團隊就會有幾個不同的角色：ERP實施顧問和ERP項目經理。另外，根據項目需要還會配備行業顧問、業務專家、技術顧問等角色，例如金融、房地產、鋼鐵等行業有針對行業的信息化顧問，人力資源、物流供應鏈、財務等模塊有各自領域的專家顧問。

一個ERP項目是不是由團隊來做實施工作，主要取決于項目的大小及難易程度，單模塊的系統實施，如財務總賬模塊的實施，項目實施工作有一個實施顧問就可以完成，在這樣的項目中其實ERP實施顧問也承擔著ERP項目經理的角色。但是大型ERP項目業務流程比較復雜，就需要團隊去做實施工作，實施顧問專注于對客戶業務的理解與實現，而其他工作有團隊的其他成員來分擔。

ERP項目經理為整個項目實施的成敗負責，ERP實施顧問為ERP項目實施過程中的某個具體工作項負責。ERP項目經理承擔了一定的團隊管理職責，ERP實施顧問在項目實施期間需要向項目經理負責。一般來說，管理信息化行業的新人是從ERP實施顧問入行，ERP實施顧問具備一定的經驗以后可以升任ERP項目經理，也可以向專家級顧問發展。

ERP實施顧問，職業穩定、體面，崗位收入偏高，一直是求職者向往的職業，但ERP實施顧問對求職者的綜合素質較高，求職者往往難于逾越行業門檻。近年，管理信息化行業發展較快，ERP實施顧問和ERP項目經理這些信息化人才顯得十分短缺，行業也出現了用友管理軟件學院這樣的行業人才培養機構，為應屆大學生和職業轉型人群快速跨入管理信息化領域成為ERP實施顧問打開了一扇方便

之門。同時，用友學院的ERP項目經理高端班也為ERP顧問及其他IT從業者向ERP項目經理高端人才發展創建了一個新渠道。

第五篇：一個ERP實施顧問的項目實施心得

一個ERP實施顧問的項目實施心得

ERP實施成功率較低，有多方面的原因，接下來的幾篇文章，將分享我數年來實施工作中積累的一些經驗，正是這些經驗，使我負責的項目有著非常高的成功率，包括多家上市公司，同時，有數家成為國內某知名ERP軟件公司的集團戰略客戶。

實施成功第一步：抑制需求

如果說，成功的銷售人員是在售前的過程中給客戶繪制美好的藍圖，并且無限制地擴大客戶的需求，讓客戶認為信息化可以解決所有的問題，從而愿意掏更多的錢來投入信息化的話。那么，成功的實施顧問在與客戶進行接觸初期，最主要的工作就是讓客戶狂熱的頭腦降溫。

看官們會問：這不是不負責任嗎?

錯，這才是負責任，如果說有不負責任的地方，那也只能說銷售人員有些過了，但對實施顧問來說，這樣做才是真正地對客戶負責任。為什么呢?原因很簡單：ERP其實是一個管理工具，而一旦涉及到管理，那就變得復雜起來，而面對復雜的問題怎么辦?那就是讓它簡單化，只有將問題簡單化，先解決能解決的，能見效的，才有可能持續優化下去。多數人會認為實施是一個階段性的工作，一旦上線就結束了，而總結實施成功的企業，你會發現，實施是一個持續改善的過程，沒有終點。而簡單化的最好方法就是，在項目會議中，當客戶提出要解決許多的問題時，首先告訴客戶：對不起，ERP不能解決所有的問題。

當然，拒絕客戶需要勇氣，也需要技巧。對于優秀sales來說，要學會任何時候都不說“不”，而實施顧問，則要學會有勇氣說“不”，也需要學會有技巧地說“不”。

所以，澆冷水的工作要逐步來做。

在項目啟動大會上，一定要提到一個觀點：管理問題的解決方案永遠沒有最好，因為它需要付出高昂的代價，所以，我們要學會選擇最適合的解決方案。(項目啟動大會是實施顧問的第一次閃亮登場，后面還會有專題來探討如何開好項目啟動大會)

在項目需求調研的過程中，一旦客戶提出難以解決的需求，就一定要弄清楚他們為什么要強調這個需求，他們目前手工是如何處理的，如果不解決會帶來什么問題，會不會成為影響實施成功的關鍵障礙?如果必須要解決，那么，解決帶來的成本與風險有多高，需要實施方付出多少成本，而客戶方又需要投入多少成本(非貨幣的)。當然，一般情況下，真正影響實施的關鍵需求應該是在售前階段也就知道了的，換句話說，應該是已經評估過可以解決的，否則，那就是銷售太不負責任了。

項目需求調研時，切記，不要輕易回答客戶這個可以解決，這個不能解決。也就是說，需求調研除了你問必要的問題以外，嘴巴就可以休息了，讓耳朵和手工作就可以了。當所有的客戶需求整理出來之后，再進行分類：一類是軟件可以解決，并且能帶來關鍵效益的，放在首位;接下來一類是軟件可以解決，客戶領導非常關注的需求，放在第二位;第三位則是軟件可以解決，普通操作者關注的需求;另一類是軟件很難解決甚至無法解決的：也要分類：首先關注領導關注的問題，這一類問題通常比較好解決，因為領導比較容易通過“講道理”來說服;而另一類是普通操作者關注的，這往往是影響實施成功的關鍵所在：如果沒有做好這方面的工作，要么是當時就逼著你解決，要么就是以后的應用過程中出現這樣或那樣的問題。那，如何來解決這方面的問題呢?

這就體現了實施顧問的溝通技巧：首先，要做到有禮有節：先要以理服人。既然已經知道他們提出來的需求原因，以及評估了不解決的后果，也評估了解決要付出的成本，那么，就可以拿出來分析：“……，綜上分析，如果要解決這個問題，我們會付出巨大的努力，并且會增加項目實施的周期與風險，我們認為，這個問題可以放待以后再來討論?！边€有就是拉著虎皮當大旗：善于利用與客戶高層管理或項目經理的良好關系，在出現分歧時，要么拿著“領導語錄”先定方向，要么直接拉著領導來表態。二是恩威并施。一般情況下，在實施過程中，總會碰到幾個“魔鬼”(指有個人目的的反對者)，也會碰到幾個“天使”。對魔鬼，一定要分析是什么原因讓他變成魔鬼的，然后，從根本上想辦法中立他，如果不行，就在適當地時候讓他犯錯，并借此來打擊他發言的積極性。而天使，則要樹典型，讓他成為整個項目中的發言人，風向標。可能看官們會說，這哪像在實施呀，更像是政治斗爭。沒錯，好好總結一下，你會發現，80%以上的企業在實施ERP的過程中，會完成一次權力的變更——并不一定某個人上下臺，而會讓某個人的權力或權威發生微妙的變化。

話回正題：通過各種技巧或方法，將客戶的需求規范到這樣的范圍以內：軟件可以實現或變相實現，領導關注，能馬上見效益的。其他的，都要想辦法不解決或“拖”。拖字訣是非常有效的：人們通常會忘記自己曾經說過的話，做過的事。

作為實施顧問，你要經常問自己：是我在主導項目，還是被客戶牽著鼻子走?