第一篇:一個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.數據準備
數據準備的重要性無庸贅言,要各種場合反復強調了基礎數據的重要性,并要求企業采取切實的措施來保證這一點。
在準備數據之前,成員要準備一份“數據準備文檔”,在該文檔中要明確如下內容:數據準備時間,范圍。即何時完成,準備何時的數據,準備哪些數據。
明確雙方責任。我們一般要求客戶來準備基礎數據,并保證數據的完整性、正確性(實際也只有客戶自己才能做完后,才知道數據的真確與否,一定要盯牢客戶完成數據的測試);項目組只提供數據準備的要求、格式。
數據準備的要求。客戶必須按照項目組要求的格式來準備,這一點非常重要,很有好處:
(1)可以保證數據的完整一致。比如說,要準備供應商資料,我們在Excel中準備好空
白如下表格。針對這個信息我們提供的一個更加詳細的說明方式,讓其自由填寫。但以上表格中的數據是必須填寫的。這樣每個準備供應商信息的人,都知道供應商資料應該包括:供應商名稱、編號、地址、稅號/帳號、聯系人等。
(2)方便核對數據。一旦在Excel中準備好數據,并核對無誤后,就需要輸入系統,輸完以后,再用系統生成并打印報表(但我們沒有這樣做,我們自己準備一個數據庫,在瀏覽器的界面,讓客戶自己直接在瀏覽器的界面填寫,然后提交到數據,這樣就減少了打印重新填寫或導入的步驟,比如,對上述供應商資料,我們可以從系統輸出一份報表,去和原始的數據核對,看看在輸入過程中是否出錯即可)。
(3)如果基礎數據量很大,一般就需要開發專門的數據轉換程序,這樣更需要按一定格式準備數據,否則,數據轉換程序不會正常工作。如果企業本身沒有其他系統(現在一般企業都沒有),即可讓其直接進行輸入。
在實際工作,很多客戶一開始感到不理解,認為沒有必要一定按照某種格式準備,作為成員一定要和客戶溝通,解釋重要性。
8.二次開發
在市場經濟的調節下,組織變動在公司中是司空見怪的,如果在項目過程中發生的話,其項目內容(人員、系統設置和數據)也必須跟隨著變化,這個變化是很糟糕的。如果變化是頻繁的,所以程序結構和維護流程不停的變更,有時會導致系統實施無期限。
ERP設計本身應是靈活的,對于企業結構有一定的適應力,當然在項目中也應該控制企業的變動。這個問題需要分兩方面來看,首先,ERP系統立意要高,要高到和公司組織結構規劃一致(當然對于企業本身也應該考慮企業重組的問題)。其次,就象人在適應社會的變化以前會經歷襁褓期,但我們也該注意在ERP實施的襁褓期減少不必要的震蕩,使項目成功完成。
9.系統正常運行
上述工作均完成后,我們的系統就是要正式運行了。
1.驗證設置是否正確。比如各種基礎數據輸入后,經檢查,均正確無誤,但系統生成結果就是不正確。這種情況下,我們就需要檢查是否是設置問題。諸如此類的問題很多,需要
一一驗證。
2.制訂各種業務規則。上了系統之后,許多新的業務流程和企業原有的業務流程不同,而最終用戶往往習慣了以前的做法,短期內可能不適應。為了確保系統真正用起來,必須做好以下幾點:
(1)做好培訓工作。培訓系統的操作和系統的業務流程。
(2)制訂詳細的業務規則,規定企業各種業務在系統中是如何處理的。并讓每位相關的最終用戶知道、理解。
(3)制訂必要的制度,確保按規定操作,特別是在使用系統初期,完善制度尤為重要。
第二篇:一個ERP項目經理的一些實施體會
一個項目經理的一些個人體會
本人做項目經理工作多年,感到做這個工作最要緊的就是要明白什么是因地制宜、因勢利導,只有最合適的,沒有什么叫對的,什么叫錯的,項目經理最忌諱的就是完美主義傾向,尤其是做技術人員出身的,喜歡尋找標準答案,耽誤了工作進度,也迷茫了自己。以下是本人一些做項目的個人體會,寫出來供大家指點,在討論過程中共同提高水平。
項目開始階段是一個最重要的階段。項目經理在接手一個新項目的時候,首先要盡可能地多從各個方面了解項目的情況,如:
1.這個項目是什么項目,具體大概做什么事情,是誰提出來的,目的是解決什么問題。在國內很多客戶都很不成熟的情況下,千萬不要根據項目的名稱望文生義地去想象項目的目標。一個名為“辦公自動化”的項目很有可能在你進場以后一個月才發現客戶其實需要的是一個計算機生產管理輔助信息系統系統。前期了解情況的工作越詳細,后面的驚訝就越少,項目的風險就越小。.這個項目里牽涉哪些方面的人,如投資方、具體業務干系方、項目建成后的運營方、技術監督方等等,很多項目里除了業主單位的結構很復雜以外,還有一些其他單位也會牽涉進來,如項目監理公司、業主的行業主管機構等。項目經理需要了解每個方面的人對這個項目的看法和期望是什么。事先了解各個方面的看法和期望,可以讓你在做項目碰到問題的時候,就每件事情分析哪些人會在什么方面支持你,哪些人會出于什么目的反對你,從而提前準備聯合朋友去對抗敵人,讓事情向你所希望的方向發展。沒有永遠的朋友,也沒有永遠的敵人,只有一致的利益,這句話作為項目經理是一定要記住的;
3.基本了解了客戶的情況后,下面的事情就是了解自己公司各方面對這個項目的看法。首先是高層領導是否重視,這個決定了你在需要資源的時候,公司是否會根據你的要求提供最有力的支持。領導口頭肯定是說支持的,你需要做的是了解公司對這個項目的實際期望,是想把項目越做越大還是想賺錢?是想做樣板工程還是干脆想敷衍了事,公司領導對項目的態度決定了你做這個項目的戰略,而這個戰略方針將對你做項目計劃產生直接的影響;
4.在做整體項目計劃前,還要大致計算一下你手上的資源。首先是時間,現在市場競爭激烈,往往很多項目要求在幾乎不可能的時間范圍里完成。對于這一點,你在做項目的風險控制計劃的時候要充分考慮。其次是人員,根據項目預算和已往經驗,大致計算一下未來的項目小組有多少種角色,每個角色目前公司是否有人,是否能完全歸這個項目使用,是否需要另外招聘一些人員,招聘的準備工作要盡早
啟動。最后就是一些設備的準備,項目所需大件關鍵設備要盡早預定,以后不管發生設備等人還是人等設備的情況,浪費的都是你的時間;
5.現在是做項目說明書的時候了。一份好的項目說明書不僅將要做的事情描述得很清楚(主要是講做什么,而不是說怎么做),而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情,也讓客戶的業務人員(一般不懂技術)知道項目做成什么樣就算完成了。簡單地說,項目說明書描述項目做哪些事情和每件事情做到什么程度以及如何檢查每一個結果。
6.是到做總體計劃的時間了嗎?不,你現在已經知道了客戶的目標和你手上的資源,那么做計劃以前,你還需要和你的經理和客戶充分溝通資源的問題。因為很多資源是還不明確的,你需要寫一份報告,詳細分析這個項目的風險以及對資源的需求情況。如果一些問題不能得到解決的話,將發生什么樣的后果。如果資源不夠,就要高層改變策略,增加對這個項目的投入。甚至在條件許可的情況下,有些公司會放棄這個項目??傊瑳]有人能完成一個不可能完成的任務,如果項目經理不能盡早發現風險,那么就只能去當烈士了。
7.明白了要做哪些事情和你手上的籌碼以及你做這個項目的總體策略,現在是成立項目小組的時候了。很多項目經理都沒有自己選擇組員的權利,那么,就盡量發揮你的影響力去尋找那些你想要的人吧。成員的組成根據項目不同,相差較大,很難有什么具體要求,但是,一定要有精通客戶業務的人,很多小項目里,這個人就是項目經理本人,大項目里會配備行業專家(Industry expert),這樣和客戶溝通起來才不會雞同鴨講,雙方才可以相互理解。我經??吹降那闆r是我們的技術人員和客戶交談時滿口的專業術語,結果搞得客戶一頭霧水,反過來,他還指責客戶不懂技術。其實,明白自己想做什么的客戶已經是很好的客戶了,不知道自己要做什么,更不懂怎么做還要指手畫腳的客戶到處存在,但是要明白,是客戶選擇了你,而不是你選擇了客戶,有了客戶你才有工資拿,心平氣和一點吧;
8.現在你要面對三群人:你的領導、你的組員和你的客戶,和這些人溝通,讓他們知道你打算怎么做,什么時候要他們做什么準備這些事情將是你的主要工作。既然溝通這么重要,那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則都是潛規則,如果你在一個部門時間做長了,對這些規則的運用覺得是一件理所應當的事情,但是,你現在面對的是多個部門甚至多個單位,不把溝通規則說清楚,你以后就會吃虧。下面的東西看起來無聊,其實還是很管用的:第一個是規定信息的流動方式和介質,是推還是拉。推的意思就是項目經理將主動發布信息,不管通過電話、郵件還是書面方式,保證將信息傳達到每個人。這種情況適合小項目,人少;拉的意思就是項目經理就是一個類似web服務器,你自己需要什么信息就去問他。當然,沒有項目經理把自己搞得那么累,他會用發布信息到公共介質的
方式公布信息,簡單的是白板,復雜一點的是項目的公共信息交互區,潛規則就是我發了你沒去看就不要說我沒告訴你。說這些看似很無聊,其實里面牽涉信息傳達不完全的責任問題。當然,這些都是指一般的方式,而且不要絕對化,一般情況下,主動溝通和被動訪問是同時存在的,尤其是對領導,項目經理更加應該主動去和領導溝通。第二個問題就是文檔問題,很多人怕寫文檔,但是項目經理一定要牢記“好記性不如爛筆頭”的道理。有理有時候為什么會說不清呢?就是因為沒有證據。所以項目經理開始就要和客戶說清楚有些文檔是必須簽字的,比如項目經理的項目日志,每個星期至少讓客戶簽字,另外所有達成共識的東西,比如會議紀要,甚至領導的講話記錄,都要寫成文檔,雙方簽字,這樣以后扯皮的時候,就能做到有據可查。記?。赫f了的就和沒說一樣,只有寫下來大家簽字后才算真正發生了的。還有一些問題,比如你提交的報告,給領導(包括本方領導和客戶領導)做一個選擇題,結果領導壓住不批,讓你無所適從,結果拖延了進度。這時候,你可以等,但是注意要留記錄,標明是誰的責任;另外,如果你在開始階段就和領導商定:如果批示提交三天后沒有得到領導答復就算對方同意,這樣你就會主動很多。再比如不同事件的審批流程問題:什么等級的事情記錄在項目日志里、什么等級的事情要雙方項目經理專門簽署備忘錄、什么等級的事情要雙方領導出面簽署合同附件等等。事先想得越周到,以后的工作就越主動。
9.好了,做了很多前期工作,定義了一些游戲規則,現在是坐下來做計劃的時候了。這一節,任意找一本項目管理的書都會說得比我好,所以我就少寫一點,說一些自己的體會就是了。首先是找幾個關鍵組員,比如客戶業務專家、系統分析員等等,做一下項目模塊劃分工作。項目分成幾塊去做,每一塊完成什么,模塊之間的信息如何交換等等。需求定義的是做什么的問題,而這里說的是怎么做的問題。這里要強調一點:完成一個目標有很多種方式,你要選一種你最熟悉的,而不是看上去最完美的,這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動,堅持要你采用那種新技術,你就應該告訴他:你選我做這個項目,就應該容許我采用自己最喜歡的方式做事情,新技術之所以有誘惑力,就是因為吃虧的人還不多,我不希望你成為第一批受害者。采用一個計劃會讓你的工作更加明確,比如用微軟的Project軟件,你填寫完表格以后,就可以知道這個項目有多少件事情要做,每件事情需要什么資源,他們之間的前后關系如何,消耗的時間有多長,完成后有什么標志等。所有的結果最后用一個叫做甘特圖的形式表現出來。你做完這個表以后會驚奇地發現,甘特圖上項目的結束時間會遠遠落后于你的計劃結束時間(簽合同的人永遠不會先征求你的意見的)。當然,學過項目管理的人會大談什么WBS、優化路徑之類的東西,但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題,在我恭喜你挑了一個輕松活之前,請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候,你就要考慮犧牲一些任務的時間(也意味著質量)了。按照什么標準犧牲?這個項目的戰略!我們在第三節提到過的戰略。我的經驗是如果你什么都趕進度,其結果
可能就是十件事情你一件也沒做好,想想多么失敗啊。所以,把資源投到你熟悉和有把握的事情上,最后的結果是十件事情,你有三件做成了精品,三件完成,還有四件因為某些原因延誤,成績單是否靚麗了很多呢?戰略決定優先級,而正確排列事情的優先級是一個項目經理能力的主要體現。
好,現在項目已經完成了前期工作,了解了項目的目標、搞清楚了手上的資源,制定了項目的策略,然后編制了項目的整體計劃,項目進入實施階段。進入這個階段反而是項目經理比較空閑的時候,不像前期的時候項目經理要象記者一樣到處和不同的人接觸,搞清楚他們在說什么,努力猜測他們在想什么和他們的真正目的,那才是最累人的事情。當然,小項目的項目經理往往自己也是一個資源,要做很多事情,這時候反而比誰都苦。項目經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意,除非你需要對方給你支持,那么你才需要講得具體一點,否則,告訴他一切正常就可以了,而且態度要積極一些,千萬不要說一些領導不懂的細節,比如:“王局長,最近項目進度還算正常,就是JVM經常發生一些內存泄漏的情況…”王局長:“(*&$@@”。和自己的領導匯報也要注意這個問題,除非他是一個技術高手,你需要他的技術經驗,否則一般就匯報進度是否正常以及有問題時你的對策和打算就可以了,有些需要他支持的地方,比如資源調用需要說詳細一點。
和組員開會,除了一些項目進度跟蹤會議以外,還有很多討論會,需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員,他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強(如果總結得不對,歡迎大家拍磚),所以,你作為會議的主持人,只要負責提出問題和記錄下他們的觀點,千萬不要做評判者的角色。一個問題,有很多方面,從不同的角度看,現象是完全不同的,想想盲人摸象的故事吧。這些技術人員,他們往往精通一個方面,就自己的角度發表見解,除非一些很特別的情況,你都應該認為,他們提出的方案,從他們的角度來看是最合理的。你的長處是掌握事情的優先級,評估各個方面的輕重緩急,從而根據他們的意見得出一個合適的(而不是正確的)方案。所以,在會議上,你要充分尊重每一個人和他的意見,夸獎那些意見提得比較好的人,千萬不要把會議帶入無休止的爭論(你要讓大家知道事情不是非黑即白的,而是多元的,唉,我們的教育惹的禍…)。會后,你自己寫文檔,做決定。會議上大家的面子都被照顧了,自然實施起來的阻力就小,如果還有意見的,你就私下找他聊,如果還不能說服他,你就要讓他明白,因為你負責這個項目、你擔當風險,所以,這個優先級應該你來判斷。組織中的高層,并不見得水平會比一般的成員高,但是,他要承擔組織的風險,加之信息的不對稱性,所以,對事情的優先級的判斷肯定比下屬強。
在開發過程中,內部管理還要注意的一點是時刻強調以驗收為目的的思想,每個任務的最終可交付成果一定要是可以被檢查的,比如,【界面要求:美觀大方、簡潔明快】,這個要求我就不知道如何檢查。所以,給開發小組布置任務的時候就要考慮如何檢查結果,比如我見過一個計劃,里面有一個任務
【開發人員熟悉EJB編程】,這個任務,除了讓這些人去參加一些專業認證考試,否則,結果很難被檢查。所以,時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情,我聽說有些老項目經理拿到項目是倒排計劃的,即首先看如何驗收和驗收標準,然后決定工作計劃。很多項目開始了很久,還不知道如何驗收,那么這個項目出問題的可能性就很大了。做項目就是為了驗收,我們的角色不是研究機構,我們的目的就是在付出那么多勞動后得到結果。另外我插一句:我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流,很容易引起沖突和矛盾(技術人員的本性決定的)。我的做法是項目經理和項目實施人員到現場,軟件開發人員還是在公司做項目。項目實施人員就是初級項目經理,他們了解自己的產品,懂得一些客戶的業務,關鍵是在于他們具有良好的溝通能力,俗稱“皮厚”。他們是客戶和研發人員的橋梁,其職業方向也是很機動靈活,以后可以有很多方向可以轉,比開發人員的路要寬得多。
接著,我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種:一種是部分更改了原先的目標,即需求變更;另一種是沒改變目標,但是客戶不滿意目前的實現方式,大到流程的實現,小到界面的布局,都是屬于這類。碰到這種情況是難以避免的,主要是事先溝通的不夠充分和客戶隨著項目的進展,慢慢想清楚了問題,改變了以前的思路。這時候,如果需要改并且你的戰略是容許這種情況的,那么注意下面幾點:
1.確保以前的文檔,就是記載著以前的結論的東西,客戶是否簽過字,如果沒有,趕緊把你的工作停下來,趕快再和客戶自己確認一下你的方案,然后讓他簽字,避免以后說話沒有憑據;
2.和客戶坐下來,自己探討他修改的根本目的是什么,是不是有同樣能達到相同目的,但是對你來說有代價更小的選擇?
3.(項目初期的工作)明確更改流程,一般是客戶指定一人簽字(否則客戶每個領導都有權力來插一杠子,你就廢了),以正式項目文件的方式提交給你,然后,你做評估分析,分析對成本、進度的影響,在你的領導同意后,出相應意見書,主要是要說明更改設計的原因和指出由此帶來的不確定后果(這個東西先寫出來,后面如果真的發生了,至少不是你的錯)。然后再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人簽的免責條款嗎?對,就學習那個,讓大家都意識到任何的更改都有成本和代價。
系統開發告一段落后,就進入客戶培訓、系統驗收階段,這個階段,我一般會注意以下幾個問題:
一、給客戶做培訓前,多注意一些表面功夫。很多程序員認為,既然很多系統采用原型法,有一個由粗到精的過程,那么系統的邏輯核心是否正確才是關鍵,至于界面如何,界面上的用詞是否準確,那是無關緊要的問題;而且培訓的時候也是空手上臺、信手拈來,想到哪里說到哪里,下面聽講的人不知所云,云山霧罩,培訓效果自然可以想象。我的體會是,給客戶做培訓的版本,如果你在做多次測試以
后仍然不能確定邏輯是否合乎要求,那么,你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、鏈接的正確性等等,總之不要讓客戶看到一些他不該看到的東西,否則,僅僅因為一些無關緊要的報錯就讓客戶第一印象覺得系統不穩定,那你就真的比竇娥還冤了。文檔方面,準備至少兩個文檔:用戶手冊和培訓手冊。這兩個文檔的內容很多都是一致的,但是角度完全不同。用戶手冊往往是站在系統設計者的角度,按照自己的思路,分模塊講解系統的操作和功能;而培訓手冊,一定要站在客戶業務人員的角度,根據每個角色面對不同業務的辦理,如何通過使用本系統的一系列功能來實現目標。所以,第一次培訓以前,系統界面是否完整正確、培訓文檔是否完備、培訓時所舉的例子是否有代表性都是很關鍵的因素,第一炮打不響,以后就麻煩很多。
上面講的是培訓的時候,丑媳婦要化妝好再去見公婆的問題。其實,項目實施中還有一個考驗項目經理功力的就是如何調動客戶積極性的問題。一般來說,客戶是懶的,這就是他花錢找你做事情的原因。一個項目的成敗,和客戶的配合程度很有關系。根據我的分析,一般項目中的客戶都可以分為三類:支持的、消極觀望的、抵觸的。他們人數的分布一般是一個紡錘形:支持的和抵觸的人少,觀望的人多(如果你接了一個人人都抵觸你的項目,那你還是不要做了)。首先,分析一下那些人為什么支持你和抵觸你。很簡單,于公于私兩個方面分析,上了新系統,誰的工作量有所變化?誰的潛在利益是否受到威脅?誰的崗位是不是因為新系統而消失?傳統的利益格局因為新系統的使用而發生怎么樣的變化,這些東西,都是項目經理必須去了解的,這樣,你才能團結那些支持你的人,消減那些抵觸你的人。項目經理是一個很奇怪的角色,屬于典型的責任大、權力小的角色,他能做的只有借力打力,不管在自己公司還是在客戶那里,一定要依靠別人才能完成自己的目的。只有了解哪些人會因為什么而幫助你,哪些人會因為什么而抵觸你,你才能讓客戶配合你做工作。比如上一些內部計算機輔助管理系統,其必然后果就是讓本來管理混亂時有人可以渾水摸魚的一些利益消失掉了,這樣,有些人肯定就要搗亂,到處詆毀這個系統。這時候,你就可以散布一些“誰抵制新系統就說明自己屁股上有屎”這類的論調去壓制他們,減弱他們的影響。
作為項目經理,其實腦子里就是幾樣東西:做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優先級。所謂多快好省那是人類的夢想,這四個方面都是相互矛盾的,屬于典型的又要馬兒跑,又要馬兒不吃草的類型??紤]問題的輕重緩急方面,往往是把快放在第一位,各方領導都會給你最后期限,所以保進度是第一位的;省是第二位的,企業的根本目的是盈利,如果收入不能增加的話,至少費用要控制??;好是第三位的,沒辦法,誰都想精益求精,但是,沒有強大的資源保障,質量只好先犧牲了;最后是多,客戶的要求源源不斷,如何降低客戶的期望值,讓他們從理想回到現實也是項目經理的分內工作。
驗收前,除了做好文檔工作,即可交付成果以外,多花時間搞清楚客戶的做事情流程是很重要的事情,這些在前面已經有所提及,這里就不再多說。
我對驗收最大的體會就是舉證問題。即千萬不要讓客戶這么想:你必須有證據證明你的系統是沒問題的。這樣你就沒戲了,微軟那么多天才,做了XP還天天打補丁,要你的程序沒問題,既不可能,你也沒辦法拿出證據。你要讓客戶明白,所謂驗收,就是我按照測試文檔的測試用例跑一遍,結果和預期結果一致就應該算通過了,而且還容許有一些小錯誤留在驗收后改正,他可以對測試用例提意見。所以,驗收前雙方要確認測試計劃和測試用例。如果他認為系統不符合要求,那么他應該舉證,證明這個系統和最初設計相背離的。所以,參考法律概念,千萬不要舉證倒置。另外,認為系統完美了才能驗收的想法也是錯誤的,軟件開發合同里一定要注明驗收以后維護期的費用問題,否則,客戶擔心一旦驗收就得不到你們的支持,自然不配合驗收,那么,你這個項目經理就很難交功課了。
第三篇:erp項目實施
erp項目實施
企業實施項目是一項非常繁重的工作,需要建立一支高效、精干的項目團隊,才能保證ERP實施工作的成功。為了確保ERP實施工作的順利進行,企業必須建立相應的組織機構,把各項工作落實到人,并加強ERP實施項目的領導和管理,為項目的實施提供組織上的保證。
(一)組織工作的重要性
在ERP實施項目的組織機構中,必須由以下四方面人員組成,即企業領導、企業IT技術人員、各科(處)室領導及管理人員和ERP供應商的實施顧問組成,其中動員各部門的管理人員參與項目的實施極為重要。
誰是企業ERP系統應用的主人,這樣一個簡單的問題,在一些應用ERP的企業中一直沒有搞清楚。在一些企業中把ERP系統的實施和應用工作都認為是計算機中心人員的事情。管理科室的領導和管理人員袖手旁觀,不積極配合,作為份外的事。在這種情況下,系統必然失敗。這里關鍵問題是沒有搞清誰是ERP系統的主人的問題。ERP系統的需求應來自管理的第一線,是為了改善現行管理才使用ERP,項目安裝成功后也是一線管理人員來使用。因此ERP項目的實施和應用,從一開始管理部門的領導和職工就應積極參與,作為自己的事情來對待。計算機技術人員只是處于一個技術支持和技術服務的角色。當然由于我國企業管理比較落后,對計算機技術缺乏了解,在系統開發的前期,企業計算中心人員要負起更大的責任,要起到技術引進和啟蒙教育的作用。但IT人員千萬不能一切包辦代替。企業要采取一切措施爭取一線管理的領導和職工盡快地進入角色,與IT人員積極配合,努力學習和掌握ERP系統的知識,積極參與本部門相關子系統的實施工作,詳盡地提出自己的需求和意見,盡快掌握ERP系統的有關應用知識和操作技術,只有這樣才能出真正作好ERP系統的應用工作,才能使ERP系統在企業獲得成功。
(二)ERP項目實施工作的組織方案:
在企業開展ERP實施工作時,必須建立一個相對穩定的組織機構,才能保證ERP項目實施的順利進行。下圖給出了項目實施建議的組織方案。本建議方案是一個兩層的組織機構,其中上層ERP項目實施的領導小組,是該項目的決策和領導機構;第二層ERP項目實施具體工作執行者,是一個高素質的團隊。ERP實施項目的組織方案
(三)各組織機構的職能
(1)ERP實施項目領導小組(或委員會)
A、組成:
ERP實施項目領導小組是由企業高層領導、各部門級領導和ERP供應商的咨詢顧問組的負責人組成。其具體組成是:
·組長(或主任)由一名廠(公司)級領導(最好是第一把手)擔任
·成員:
-廠(公司)級各位領導
-有關處(科)室、車間(分廠)領導
-計算中心負責人
-關鍵崗位管理人員
-ERP供應商實施項目顧問組負責人
B、職責
ERP實施項目領導小組負責對ERP實施過程中發生的重大問題進行決策,把握咨詢工作的目標和方向,控制工作的進度計劃和工作質量,提供所需資源和協調所發生的資源竟爭和發生的矛盾。其具體任務是:
·決定ERP實施項目投入的人力、物力、資金等各項資源,并在資源發生矛盾時進行調度和協調;
·挑選參加ERP實施項目小組工作的成員,任命“項目小組”負責人;
·審核批準ERP實施項目的目標、范圍和原則;
·審核批準ERP實施項目年、季、月度工作計劃;
·參加ERP實施項目階段性會議,聽取并指導項目小組工作報告;
·決策企業管理模式、方法、流程、組織機構等重大調整問題;
·審批有關ERP實施工作的各項規章制度及考核辦法,制定獎懲制度和激動機制,鼓勵參加項目的全體人員努力完成本職工作;
·決策有關ERP實施工作中各種重大人事變動;
·審批ERP實施過程中重大技術方案和結論;
·主持ERP實施工作各階段成果的驗收和鑒定。
C、活動方式
領導小組(委員會)不是常設機構, 原則上每月召開一次例會, 聽取工作匯報, 檢查工作進度, 發現問題, 提出解決方案。如遇重大事件發生時, 可隨時召開會議。
D、對ERP實施項目領導小組組長的要求
1)領導小組組長應是企業一位高級資深領導人,最好是企業的第一把手,或第一把手委托的一位付總。
2)ERP實施項目的領導者,必須對企業信息化建設有著極大的熱情和積極性,堅信必須進行改革和創新才能使企業充滿活力,在激烈的竟爭中立于不敗之地。并把這種信念感染企業中的每個職工,使他們對項目充滿信心。
3)領導小組組長必須要有足夠的權威,他有權分配ERP實施項目所需要的有關資源,包括人力、物力和財力。特別在人事調動中,要保證ERP實施工作中需要的人才,而這些人才往往也是日常管理工作中的業務骨干,只有企業的最高領導才能進行統籌安排,才能在各項資源發生矛盾時做出有效的協調。
4)ERP實施項目的領導者要有憂秀的氣質和百折不撓的精神,他應該善于把任務的目標與項目組的行動統一起來。領導者必須是一位真正的領袖,他不是僅能命令別人去做事,而是能讓別人能在做事時充滿激情。
5)高級項目領導應該積極地參與ERP實施的實踐,在實踐活動中與各方面人員溝通,了解真實情況;同時,又不要陷入到鎖碎的日常事務之中,隨時注意把握大方向。
(2)ERP實施項目小組
A、組成:
1)組長(1人), 副組長(1-2人)(建議: 由企業和ERP供應商實施顧問組各選派一人,分別擔任正、副組長);
2)企業IT人員(或計算中心人員),包括系統分析人員和軟、硬件人員;
3)與ERP實施有關的各處、室、車間選派參加ERP實施工作的人員;
4)ERP供應商的實施顧問。
B、對項目組的基本要求:
1)ERP實施項目小組,要全面參與企業ERP實施項目的全過程,要確保管理咨詢項目的順利實施和完成;
2)項目小組是由ERP供應商的實施顧問和企業各部門管理骨干組成。項目組中各部門的管理人員要能準確地描述企業的管理現狀和業務流程,在ERP項目實施活動中,全力投入項目的實施工作;
3)項目小組是一個高效、團結、協調的團隊,要求這個團隊要有一定的相對穩定性,并在項目執行期間小組成員要100%的時間投入項目實施工作。只有這樣的團隊才能推進項目的成功;
4)企業抽調的項目小組成員,要熟悉本部門及相關部門的管理業務;有豐富的企業管理經驗和獨立解決問題的能力;有敏捷的思考能力和較強的工作能力;在企業內部有一定的影響力,工作積極熱情,有責任心,愿意投身于該項目工作;有較好的溝通能力和較好的人際關系。
5)無論是企業內部的人員還是企業外部的人員,都要打破傳統思想的約束,發揚創新精神,積極接受新新鮮事物。
C、職責
負責ERP項目全過程的實施工作, 包括:
1)全面執行項目領導小組的決定,達到項目的預定目標;
2)根據項目領導小組制定的總體目標和進度要求,制定并執行項目的實施進度計劃,并定期向領導小組匯報工作,聽取指示;
3)參加ERP實施項目顧問組織的有關ERP技術的培訓;
4)組織并參加現場業務調查和分析工作;
5)參加現行企業業務流程的調查、描述、分析和憂化工作;
6)參與“ERP建議方案”的設計和報告的編寫工作;
7)承擔計算機硬件系統和網絡建設的工作;
8)配合ERP軟件供應商進行應用軟件的安裝、調試及維護工作,并在調試過程中學習和掌握軟件的原理、操作維護方法和簡單的二次開發方法;
9)在實施顧問的指導下,組織整個系統的編碼工作和數據準備工作,確定編碼方案,指導各管理部門的應用小組人員進行編碼和數據準備工作;
10)在實施顧問的指導下,組織各應用部門的領導和管理人員充分了解ERP軟件系統方案,對比實際需求進行分析,提出對軟件系統的用戶化修改意見,經過有關方面人員充分討論后最后確定用戶化修改方案,并組織方案的實施;
11)負責對最終用戶的操作培訓工作;
12)在實施顧問的指導下,協同企業管理部門制定對ERP系統實施項目的管理規章制度和參加實施人員的獎懲辦法;13)負責組織ERP系統實施各階段的成果驗收;
14)遵照“ERP項目實施進度計劃大綱”,編制各實施小組的月、周工作計劃,并定期向領導小組匯報;
15)組織ERP系統的最終測試和驗收;
16)負責ERP軟件系統正式運行后的維護工作和簡單的修改、開發 工作。
D、對ERP實施項目小組負責人的要求:
1)實施項目小組負責人直接負責項目的實施工作,要求其全部時間投入此項工作;
2)由ERP實施工作工作涉及企業管理模式的改造和軟件在各管理部門的應用,因此要求項目小組負責人不但要熟悉計算機技術、ERP軟件技術,還必須有較深的企業管理知識,要對企業現行管理較為熟悉;
3)為了便于組織各部門人員參加ERP系統的實施工作,項目小組負責人應具有較高的職位和威望,對上能與企業高層領導進行較好的溝通,對各部門之間又具有很好的協調能力;
4)實施項目小組負責人應有較強的管理才能,有序地安排工作和協調資源的使用,在項目執行的過程中能有效地控制時間進度、項目的質量和成本;
5)實施項目小組負責人要協調ERP軟件供應商實施顧問和項目小組其他成員之間的關系,在工作中發生矛盾時,要善于進行調節,妥善處理矛盾,使整個團隊團結協作、思想統一,才能保證項目的順利完成;
6)管理咨詢項目小組負責人要有極強的應變能力和堅忍不拔的精神。只有這樣,才能在項目發生變化時,領導團隊不迷失方向;
7)實施項目小組負責人要有改革和創新的精神,能夠接受新鮮事務,在ERP建設中引進先進管理模式和現行管理改造中,起到積極的推動作用。
3)各處(科)室、車間項目實施小組
A、組成·組長: 由各處(科)室、車間第一把手擔任組長
·成員: 所涉及崗位的管理人員
B、職責
1)負責本部門涉及的子系統、各功能模塊的實施工作;
2)負責本部門子系統實施中的數據準備和錄入;
3)負責本部門子系統的試運行和系統維護工作;
4)負責用戶化修改方案的提出、需求調查和設計的配合工作、實施和驗收等;
5)制定本部門項目實施“月、周工作計劃,并向”領導小組"做月度工作匯報。
C、對人員的基本要求
參加項目實施小組的人員必須是對企業信息化建設積極熱情,能
全身心地投入這項工作。ERP是一項新技術,因此小組人員必須對新知識有學習的興趣和學習的能力。小組人員要精明強干、吃苦耐勞、善于團結別人。精通本部門的管理業務。
ERP實施的組織工作的核心是要做到以人為本,充分調動企業全體人員的熱情和積極性,包括領導的積極性和職工的積極性。為此,在ERP整個的實施過程中都要抓好教育和培訓工作。這樣整個企業才能統一思想、團結一致,使ERP系統的實施工作成功。
第四篇:一個ERP實施顧問的項目實施心得
一個ERP實施顧問的項目實施心得
ERP實施成功率較低,有多方面的原因,接下來的幾篇文章,將分享我數年來實施工作中積累的一些經驗,正是這些經驗,使我負責的項目有著非常高的成功率,包括多家上市公司,同時,有數家成為國內某知名ERP軟件公司的集團戰略客戶。
實施成功第一步:抑制需求
如果說,成功的銷售人員是在售前的過程中給客戶繪制美好的藍圖,并且無限制地擴大客戶的需求,讓客戶認為信息化可以解決所有的問題,從而愿意掏更多的錢來投入信息化的話。那么,成功的實施顧問在與客戶進行接觸初期,最主要的工作就是讓客戶狂熱的頭腦降溫。
看官們會問:這不是不負責任嗎?
錯,這才是負責任,如果說有不負責任的地方,那也只能說銷售人員有些過了,但對實施顧問來說,這樣做才是真正地對客戶負責任。為什么呢?原因很簡單:ERP其實是一個管理工具,而一旦涉及到管理,那就變得復雜起來,而面對復雜的問題怎么辦?那就是讓它簡單化,只有將問題簡單化,先解決能解決的,能見效的,才有可能持續優化下去。多數人會認為實施是一個階段性的工作,一旦上線就結束了,而總結實施成功的企業,你會發現,實施是一個持續改善的過程,沒有終點。而簡單化的最好方法就是,在項目會議中,當客戶提出要解決許多的問題時,首先告訴客戶:對不起,ERP不能解決所有的問題。
當然,拒絕客戶需要勇氣,也需要技巧。對于優秀sales來說,要學會任何時候都不說“不”,而實施顧問,則要學會有勇氣說“不”,也需要學會有技巧地說“不”。
所以,澆冷水的工作要逐步來做。
在項目啟動大會上,一定要提到一個觀點:管理問題的解決方案永遠沒有最好,因為它需要付出高昂的代價,所以,我們要學會選擇最適合的解決方案。(項目啟動大會是實施顧問的第一次閃亮登場,后面還會有專題來探討如何開好項目啟動大會)
在項目需求調研的過程中,一旦客戶提出難以解決的需求,就一定要弄清楚他們為什么要強調這個需求,他們目前手工是如何處理的,如果不解決會帶來什么問題,會不會成為影響實施成功的關鍵障礙?如果必須要解決,那么,解決帶來的成本與風險有多高,需要實施方付出多少成本,而客戶方又需要投入多少成本(非貨幣的)。當然,一般情況下,真正影響實施的關鍵需求應該是在售前階段也就知道了的,換句話說,應該是已經評估過可以解決的,否則,那就是銷售太不負責任了。
項目需求調研時,切記,不要輕易回答客戶這個可以解決,這個不能解決。也就是說,需求調研除了你問必要的問題以外,嘴巴就可以休息了,讓耳朵和手工作就可以了。當所有的客戶需求整理出來之后,再進行分類:一類是軟件可以解決,并且能帶來關鍵效益的,放在首位;接下來一類是軟件可以解決,客戶領導非常關注的需求,放在第二位;第三位則是軟件可以解決,普通操作者關注的需求;另一類是軟件很難解決甚至無法解決的:也要分類:首先關注領導關注的問題,這一類問題通常比較好解決,因為領導比較容易通過“講道理”來說服;而另一類是普通操作者關注的,這往往是影響實施成功的關鍵所在:如果沒有做好這方面的工作,要么是當時就逼著你解決,要么就是以后的應用過程中出現這樣或那樣的問題。那,如何來解決這方面的問題呢?
這就體現了實施顧問的溝通技巧:首先,要做到有禮有節:先要以理服人。既然已經知道他們提出來的需求原因,以及評估了不解決的后果,也評估了解決要付出的成本,那么,就可以拿出來分析:“……,綜上分析,如果要解決這個問題,我們會付出巨大的努力,并且會增加項目實施的周期與風險,我們認為,這個問題可以放待以后再來討論。”還有就是拉著虎皮當大旗:善于利用與客戶高層管理或項目經理的良好關系,在出現分歧時,要么拿著“領導語錄”先定方向,要么直接拉著領導來表態。二是恩威并施。一般情況下,在實施過程中,總會碰到幾個“魔鬼”(指有個人目的的反對者),也會碰到幾個“天使”。對魔鬼,一定要分析是什么原因讓他變成魔鬼的,然后,從根本上想辦法中立他,如果不行,就在適當地時候讓他犯錯,并借此來打擊他發言的積極性。而天使,則要樹典型,讓他成為整個項目中的發言人,風向標??赡芸垂賯儠f,這哪像在實施呀,更像是政治斗爭。沒錯,好好總結一下,你會發現,80%以上的企業在實施ERP的過程中,會完成一次權力的變更——并不一定某個人上下臺,而會讓某個人的權力或權威發生微妙的變化。
話回正題:通過各種技巧或方法,將客戶的需求規范到這樣的范圍以內:軟件可以實現或變相實現,領導關注,能馬上見效益的。其他的,都要想辦法不解決或“拖”。拖字訣是非常有效的:人們通常會忘記自己曾經說過的話,做過的事。
作為實施顧問,你要經常問自己:是我在主導項目,還是被客戶牽著鼻子走?
第五篇:ERP項目實施經驗總結
ERP項目實施總結
一、需求調研:
1、調研工作不夠細致,對某些特殊業務的理解程度不夠深入,造成以下幾種情況:A:在實施過程中拖延工期;B:按照原定方式設置后,業務無法流轉,導致數據基礎數據錄入后的返工;C:需要二次開發才能實現的功能,無法變通,導致加重實施工作的難度,甚至會延誤工期;這些情況的發生都會使操作人員產生抵觸情緒,嚴重者會引起雙方的矛盾,不利于項目的順利實施。
2、在調研過程中一定要做到全面細致,尤其是對用戶的比較特殊的業務,應詳細的了解業務的操作流程,并收集相關資料,調研結束當天就應根據紀錄,經調研小組討論后,出具相關調研總結報告;調研工作的不到位會直接影響到合同的簽訂,雙方責任的明確、以及軟件功能的界定。
3、必須有明確的需求,一般我們的客戶是在我們業務人員的極力推動下上ERP的,在現有產品條件下不可能象SAP那樣滿足用戶的所有需求,所以實施人員必須了解用戶的關鍵需求,如:是資金積壓太多、還是市場預測不準。滿足了關鍵需求項目就算成功了一大半,能夠比較體面的結束項目。
4、搞清楚哪些問題在ERP中處理哪些問題不能在ERP中處理。用戶曾經提出這樣的需求:能不能自動測量儲油大罐中油的容量,實際上這是自動控制方面的問題,肯定不能放到ERP中。
5、由用戶在消化軟件的基礎上設計自己的業務流程,實施顧問給出改進意見。因為用戶對自己的業務是最熟悉的,執行起來也比較方便。
6、項目調研雖然重要,但由于在調研時,初訪者對ERP的認識是很有限的,也不懂軟件功能,經常會出現問非所答,所以調研報告的水分是很高的,只能作為實施過程的參考,并不能按調研報告去實施,否則實施過程必會出現過多的反復。調研報告水分高的另一個致命原因是被訪者報喜不報憂。
二、系統初始化:
1、正式初始數據之前,發現基礎數據準備不夠充分,從而加重了實施過程中勞動強度;甚至在整理過程中,用戶才發現自己的賬目比較混亂,比如:有時產生倉庫賬和財務帳不符,倉庫賬和實物賬不符等,這些都可能拖延實施的進度。
2、在初始數據過程中,對用戶的各種數據和業務,要做出正確的分析和判斷,盡可能發揮軟件的優勢,避免返工。
3、不要輕易答應用戶將老系統中數據轉入新系統,否則可能會加重實施人員的工作負擔,造成數據不準確性隱患,而且有時一些不正確在當時可能不被發現,從而對以后的維護工作帶來難度。如果確實需要通過sql或小工具導入,一定要反復做測試。
4、千萬不要替用戶做初始數據和初始化,不管企業有何理由。這頂并不漂亮的帽子會使用戶只知其然而不知其所以然。
5、部分操作人員的重視程度不夠,在準備數據或錄入數據過程中,工作不夠認真、仔細,可能產生大量的重復性錄入。所以我們應要求企業建立審核機制,做為實施顧問,要經常在軟件界面中查詢相關數據,幫助分析數據的正確性,發現錯誤及時糾正。
6、在初始化時,注意權限設置,像維護工具、各個系統的系統參數設置、基礎數據維護、單據記帳等功能權限不要賦予無關的人員。
項目組織:
1、ERP項目是“一把手”工程,而不應僅是電腦室的工作,而且用戶的項目負責人至少應是副總或相當于此級別的人員,如果項目負責人不能在項目實施中,發揮領導作用,會產生部門之間的責任不夠明確,造成部門之間相互推諉,推卸責任,互相踢皮球。
2、企業認為上ERP完全由軟件公司一手承擔,他們只是配合角色,這是不對的客戶高層領導必須重視,領導的重視并不是停留在口頭上的,也不是非要親自學計算機、學軟件。而是要在總體上安排計劃,協調人力、物力資源。而不是“你們幫著做吧,一周向我匯報一下就可以了”。
3、我方項目組的分工要合理搭配,讓項目組每個成員在這個項目上能感覺學習到新東西,工作量可以適當的再飽和一些,給每個人規定任務完成的最終時間,把他們的積極性調動起來,同時也要給他們一定的壓力,一個項目的成功與否,是一個團隊的共同努力,光靠項目經理自己是不行的,注意調動內部和外部的力量。項目管理
1.重視項目周報的編制質量和及時性。
? 項目周報是對每周項目進展情況的正體反映,涉及實施、開發、項目管理、商務等方面。所以對周報請大家高度重視,如果周報上反映的問題,相關人員沒有及時響應或反饋意見,比如需要商務經理協調的問題,大家反映了,商務經理沒有響應,那出了問題,是商務經理的責任,但如果沒有把問題及時反映,那出了問題就是項目經理的責任,所以說,不要認為周報寫了也沒有用,尤其是需要我們公司開發、高層領導協調的問題,一定要在問題剛暴露時就要反映,不要報喜不報憂。
? 周報不僅僅是給客戶看的,對不方便客戶了解的內容,大家可以一式兩份,其中一份給客戶,另一份給公司,比如對開發進度的要求、項目團隊內部問題等不方便客戶了解的內容,可以單獨一份發給公司。周報上尤其是跟計劃的對比,請大家多花點時間考慮一下,如果拖期到底原因是什么,我們項目拖期很多時候都是由于不重視計劃,不仔細分析拖期原因,結果最后就拖長了。? 對周報的報送時間請大家注意,既然我們規定是周一上午報送,就應該按時報送,這本身也是體現項目經理的項目管理水平的一方面,并且我們周報是要求對方項目經理每周簽字的,如果是上周的周報每次都是周二才給客戶簽字,客戶原意嗎?這次在石家莊辦事處的信息欄上,我看到河北區三位同事因為沒有按時交總結,被罰了50元錢,我想對于文檔報送的及時性,我們雖然不會去罰錢,但將來在項目考核上應該有所體現。
? 有時我們覺得周報編制比較費時間,建議每天可以抽出10分鐘時間記錄一下當天項目情況,周末時匯總整理一下,編寫速度會加快,另外,從鍛煉和培養的角度,項目經理也可以讓實施經理寫周報,項目經理最后審核補充。2.合理控制需求。在項目實施的過程中,企業肯定會提出這樣那樣的新需求。在滿足企業要求時,要以合同為依據,量力而行,少承諾,重信用??蛻魸M意是我們的目標,但這種滿意必須是建立在客戶合理的預期基礎上。我們必須明白,把客戶的滿意率從80%提高到100%所付出的成本遠比從0%提高到80%高的多。3.對于客戶提出的需求,不要輕易的答復能做或是不能做,跟開發經理或產品部商量后,如果不能做,一定給客戶一個讓人接受的理由,不要簡單的說‘NO’。4.具體問題具體分析,不要什么事都憑經驗去做,有時,僅憑經驗做事會發現,經驗會讓你錯誤。
5.項目組要進行‘走動管理’,不要用戶打電話給你或者反映給你了才到現場,平常即使用戶不反映問題,也常到現場走走,詢問一下各崗位有無問題,使用情況怎么樣,甚至有時拉拉家常,這樣做一方面可以及時發現問題及時解決,避免小問題變成大問題,另一方面可以增進與用戶之間的感情交流,拉進距離,雙方熟悉了,互相信任了,出現問題后,用戶也不會出現過激的反應。6.對于做ERP項目,做為軟件方,我們可以跟客戶進行協商、探討,但是也不能什么事情都依著客戶,我們有自己的實施方法、有自己的項目管理方法、有其他客戶成功和失敗的經驗教訓,在這些方面,客戶需要聽取我們的意見,比如在實施范圍、進度、實施方法方面,這方面要多跟客戶溝通,以我們為主。7.為保證客戶數據安全,防止不必要的數據泄密,發生雙方法律上的糾紛,建議在項目組內部建立客戶數據保密制度,可參考如下:
? 客戶的數據在沒有項目經理允許的條件下,不準項目組成員隨便拷貝、傳輸給項目組以外的人員(包括公司內部人員)作測試、模擬以及其他用途。? 對于客戶的數據界面,除非得到客戶方項目負責人明確書面同意,否則不允許用客戶的數據作對外演示使用,也不允許在說明書、宣傳材料中直接引用,當然,在改動客戶數據資料,以非真實數據可以引用。
? 不允許將其他客戶的數據在另外一個客戶的服務器上恢復后作測試、演示使用,如果確實需要作測試使用,只能專人專管,并且只能在我們自己的機器上作測試用,并且絕對不要讓客戶知道。
? 對于為了解決客戶問題,確實需要公司開發人員對客戶數據庫作測試分析這種情況,發到公司的數據庫必須專人專管,盡量不要放到公司公用服務器上,可以放到個人電腦上,一旦不使用后,立即刪除。
? 不要在一個客戶現場,太多的談另外一個客戶的一些業務流程以及機構設置、人員關系等情況。
? 現場實施人員在幫客戶設置權限時一定要注意嚴格設置功能權限和數據權限,尤其是配方、工資、財務、銷售方面的數據,不該設置的權限一定不要隨意給客戶設置,最好讓客戶有嚴格的權限申請流程,由專人來設置。