資訊化專案管理案例點評
鄭 偉,45歲,S集團副總裁,分管人事、資訊、財務,此次專案的負責人;
歐陽雪,35歲,S集團營銷總監,此次專案總監;
鍾 劍,33歲,S集團資訊中心實施部經理,此次專案經理;
許建國,38歲,S集團浙江分公司總經理,此次專案浙江分公司負責人;
王新水,32歲,S集團浙江分公司杭州辦事處經理,此次專案杭州辦事處負責人;
徐筱芳,27歲,S集團浙江分公司杭州辦事處文員,此次專案杭州辦事處協調員。
“什麼?只給我兩週不到的時間?”剛剛休完探親假,還沒來得及休整的鐘劍被急匆匆地叫回了總部,聽到這個他們準備了了兩年的移動商務的專案要上馬,他不知 道是喜還是憂。“是的,總裁昨天已經成立了專案委員會,銷售、市場、人事的負責人都是專案組的成員,並由總裁親自指揮。要求8月16日30個分公司的各1 個辦事處上線!”鄭偉(S集團副總裁,分管人事、資訊、財務,此次專案的負責人)高興地對鍾劍說。
“可是鄭總,您知道,專案組需要時間成立,我們需要與軟體供應商、運營商談判,還有硬體裝置採購,系統搭建、安裝、除錯、修改,需要進行各地基礎資料的收集、整理、匯入,還有……”
“不要和我說這些,這不是你一直想上的專案嗎?我已經幫你把所有需要參與的各層領導拉進專案組了,接下來就看你這個專案經理怎麼施展啦……”
聽了鄭總一番話,鍾劍沒有再做任何的辯解,在集團工作了這麼久了,他怎會不深知公司的做事風格呢?“好的,我盡力吧,這就回去準備。”
著手移動商務專案
S集團是國內一家大型的食品集團企業,總部設在上海,在全國擁有30個分公司,250個辦事處,而員工總人數更是多達20000餘人,其中終端銷售人員超 過14000人,年營業額接近60億。2003年,S集團正式成立由直屬集團總裁領導的資訊中心,總人數45人 。
作為這樣一家大型的集團分銷型企業,對多個分公司的統一管理和渠道終端的掌控成了重中之重。為了能夠更有效地進行市場分析和預測、更好地管控終端銷售人員 的銷售行為,S集團在2004年底就開始嘗試移動終端技術在終端資料採集中的應用,並在2005年進行了兩輪技術可行性和業務可行性的測試執行,並著手加 快該專案在集團的推行。這不,專案說開始就開始了。專案的主要目標就是規範銷售行為的管理,通過使用手機為資料收集和定位的載體,管理銷售人員的行為以及 採集終端資料。
基礎資料採集遇困難
8月11日,下午1點。“鍾經理,我們發下去的資料採集到目前為止只有一半的辦事處文員回覆了,這樣下去時間來不及了。”負責收集資料的小王急匆匆地跑進 鍾劍的辦公室,氣喘吁吁的說。“趕緊讓銷售部門去催促,讓他們務必把事情落實到責任人身上。另外,現在的資料倒入問題軟體公司有沒有解決呢?”鍾劍問道。 “已經解決了,他們將負責數匯入,但需要給他們一些時間。”
8月17日,上午10點。 徐筱芳提出了新問題:目前,收集上來的資料中,除了杭州辦事處外,還有新疆辦事處和哈爾濱辦事處的資料。可是現在系統內的資料都亂了。經過檢查發現,原因是在期初進行資料準備時,文員沒有按照標準準備資料,導致資料混亂。
8月18日,下午3點。專案組緊急召開會議。在會議中,專案組決定重新整理資料,要求各辦事處嚴格按照專案組標準模板和要求組織資料;並按照進度計劃調整上線時間,將上線時間調整至9月1日。
經過這樣的一個過程,專案如期得以下發落實,9月1日,系統如期在試點辦事處上線,各辦事處的資料不再混亂。
統計報表混亂,問題層出不窮
9月15日,發現統計報表分析與日常手工報表發生嚴重不符,經仔細檢查,發現問題是:上線前銷售渠道分類沒有統一的嚴格規定,雖然在組織資料時銷售管理部 出了一套標準的銷售分類,但由於各辦的理解相同,導致資料分類錯誤。30個辦事處,28萬家終端店頭的資料被錯誤地分類融合在一起,這個亂真是理不清。
9月20日,在這樣的情況下,鍾劍和銷售管理部一起,重新整理了一套標準,並進行了詳細地分析和論證。並將專案進展的情況上報給總裁、副總裁,總裁決定在22日的銷售會議上由鍾劍來彙報這件事。
9月22日,在全國銷售會議上,鍾劍針對目前專案的進展以及面臨的困難進行彙報,全專案組在總裁的指示下,重新整理資料,嚴格按照新的標準來做,並由銷售管理部和資訊中心嚴格把關;同時,決定10月9日第三次上線,各辦事處需嚴格按照專案組的資料提交時間來做。
9月30日,收到25個辦事處的資料,但都存在問題。
10月6日,資料已經按標準整理完畢,電話通知所有總部專案成員和30個辦事處文員,7日全體加班,對資料進行檢查測試。
10月7日,晚9點。資料檢查和測試工作還在緊張地繼續,只完成了一半還不到,眼看著第三次上線時間再次臨近,鍾劍又一次陷入了困境。
全力以赴,再次衝刺
10月8日,週日,下午1點。“不推遲專案啟動時間,我請咎辭去專案經理,您請更有能力的人去做!”鍾劍高舉著手臂無可奈何地對鄭偉說。
“不要太激動嘛!有事好好商量,目前出現的問題又沒有說是你的問題。”鄭偉眼睛看著歐陽雪。
“我不同意!已經第三次推遲了,我無法向銷售分公司交待!” 歐陽雪強硬地說。
鍾
劍:“責任由我來承擔!我們的系統從8月15日到現在,存在的問題很多,原因各位也清楚。正是因為已經推遲了三次,所以這一次的上線只能成功不能失敗。我
們的系統是按周進行運作的,整個國慶黃金週,30個試點辦事處的文員都在加班加點地工作,每次資料的提交都要3輪的返復才能完成,國慶7天的假期僅我累計
加班超過100個小時。但至今仍有5家沒有將最後一版資料。而提交完整的資料匯入系統後,還需要有兩輪的資料關係建立,這些資料關係的建立只能由手工在系
統中操作。”
歐陽雪聽到鍾劍這樣說,也緩和了語氣:“那可不推遲一天?”
“不行!我們的針對業務員的運作是以周為週期的,明天是週一,推遲一天就是週二了,這樣會對系統的運作帶來很大的問題。所以,第一次操作我建立還是由週一 開始。既然是推遲,一天也是推,一週也是推,那我們將上線的時間推遲一週到10月16日吧?!”鍾劍抓住這個機會建議道。
“那……請鄭總來決策吧!”歐陽雪順手一推把難題交給了鄭偉。
“行!不過16日是最後的期限,到了這個期限還不行,鍾劍你不提出辭職,我也會提請總裁的。”
鍾劍果斷地說:“行!沒問題,這次是按我的標準的方法進行操作的,沒問題。不過,需要歐陽理解,這種專案是銷售管理全員的專案,需要各級銷售組織重視並真正地進入到專案狀態。”
歐陽雪看了鍾劍一眼,對許建國和王新水說:“兩位經理,鍾經理的話你們聽到了,希望你們積極配合。”
許建國說:“沒問題,人事經理、行政助理我已經通知了,她們隨時聽候指揮。”
王新水說:“徐筱芳一直就在專案狀態,會議前已經和鍾經理溝通過,回去後我會讓銷售主管也參與進來。這次專案是為我們終端管理服務的,我們當然會全力以赴。”
2006年10月8日,週日下午兩點四十五分,鍾劍開完專案小組會議,宣佈專案時間推遲一週,然後給各地的銷售文員發了封Email:
“……(原因分析)
“綜上所述,為了保證專案的實施質量,經請示相關領導,決定將此次新舊系統的切換時間向後推遲一週,即10月9日改為10月16日。具體安排如下:
“……
“發出這樣的郵件通知,於我是很痛苦的決定:一
個決定了的事情隨意變更是我所痛恨的,相信沒有人會希望如此。但我們都必須面對現實,我不能讓為這個專案戰鬥了兩個多月的各位同事再增加壓力了。作為這個
專案的負責人,我希望一起努力的結果是成功。在國慶長假裡,僅我個人為資料的整理和準備花去了100個小時的時間,也就是說加班了11天多。當然我知道不
只是我一個人在孤軍奮戰,還有各位辦事處的文員和專案組其他同事們。
“回想這七天,一天一道催命的郵件讓大家沒有過好‘黃金週’,甚至在中秋之夜仍舊限時要求大家提交資料,為此我感到很慚愧,同時也感到欣慰。
“對於今天上午已經組織人力開始做拜訪計劃的SH大區、WN大區、GM大區、XJ大區,以及其他為此專案而努力的所有機構及人員表示感謝!有了我們共同的努力,勝利不會遙遠。
“謝謝!謝謝!……”
合上筆記本,鍾劍終於鬆口氣,兩個月來高度緊張的情緒,終於有個回籠的時間。一幕一幕不覺得浮現:
2006年10月31日,專案第三次上線終於獲得成功,跟蹤兩週後基本無大的問題。鍾劍踏上新的征程,這半個月裡他總結了近三個月的專案問題,整理了一套更完善的專案實施方案,這次他將在一週內去7個分公司為其他沒上線的辦事處做準備工作。
報喜鳥集團周巨集鈞點評企業現場案例
S集團的移動商務專案可謂一波三折,其結局是戲劇性的,最終以2006年10月31日,專案第三次上線獲得成功而告終。之所以叫“一波三折”,主要是因為 專案的上線日期一拖再拖。回顧專案歷程,值得總結的地方還是比較多的,筆者認為問題集中體現在IT規劃、專案計劃、啟動會、資料準備、風險管理、溝通管理 和變更控制管理等方面。S集團移動商務專案實際上濃縮了資訊化專案的普遍問題,特別是有關資料整理的反覆,反映了國內企業基礎管理的薄弱,具有典型意義。 筆者從2005年開始擔任專案經理實施SAP ERP專案,採取ASAP加速實施方法,經歷專案準備、藍圖規劃、系統實現、系統準備和系統上線等專案階段,也有過類似的經歷,藉此機會總結經驗教訓,分 享給大家。S集團移動專案本身存在很多亮點,如最終專案實現上線目標等,本文不做重點闡述,本文僅僅針對存在的一些問題,談自己的看法。當然,也僅僅是一 家之詞,不見得妥帖。
首先,S集團明顯缺乏IT戰略規劃,移動商務專案準備時間達到2年之久,而專案的上馬啟動會議竟然是在專案經理不在場的情況下召開的,由此可見,該專案的 整體生命週期是有其隨意性的,反應了S集團IT規劃的缺失。專案啟動會議對於專案是非常重要的,其核心在於對專案經理的授權,明確專案高層次目標和專案可 動用資源等。鍾劍經理在專案運作當中多次推遲專案上線時間,資料提交的反反覆覆、專案經理身體力行進行專案加班加點等細節,從側面反應專案經理對資源的掌 控還是不夠的,這也是啟動會議沒有到位的結果之一。
其次,S集團移動商務專案的專案計劃制定不合理。從案例看來,專案上線的日期出現多次調整,分別是8月16日、9月1日、10月9日和10月16日,按照 專案結果,顯然專案進度是拖延了,但從根本原因分析看來,S集團移動商務專案總體計劃是非常主觀的,如專案啟動會議定下來的“要求在8月16日30個分公 司的各個辦事處上線”目標,顯然是值得推敲的。從專案管理角度看來,沒有看到專案管理計劃及其分計劃(如範圍管理計劃、進度管理計劃、成本管理計劃、人力 資源管理計劃、溝通管理計劃、風險管理計劃和採購管理計劃)。作為專案經理面對不可實現目標,雖然提出了專案進度方面的意見,但在鄭總的一番“訓斥” 下,“鍾劍沒有再做任何辯解”,這種“委曲求全”以保專案上馬的案例國內比比皆是,實際上反應了專案經理鍾劍本身對專案計劃方面經驗的缺失。作為專案經理 是為實現專案目標負責的,既然明知不可行的目標,為何要勉強為之呢?從整個案例看來,專案缺乏一個資料管理計劃,資料管理計劃包括資料在專案週期內是如何 被管理的,也包括靜態資料、動態資料的格式、收集要求、職責分工、進度要求、資料質量等方面。筆者實施的SAP ERP同樣面臨著資料的難題,除了總部的基礎資料(大小物料、BOM、供應商主資料、客戶主資料,物料資料因為行業特性,初始化達到上億條記錄,可見工作 量的巨大),還有全國600家門店的靜態資料和動態資料,特別是動態資料,涉及到資料的一致性,需要同老管理系統核對比較,困難可想而知。筆者在專案的中 期,也就是“系統實現”階段,在SAP後臺配置的同時就召開資料整理啟動會議,安排各項工作任務,且採取了有效的策略,如靜態資料提前收集、核對進入系 統,動態資料多層次、多崗位的核查等。在整個過程中,值得一提的是IT要發揮主導作用,因為資料處理是一件很細緻、很煩瑣、工作量很大的事情。我們採取的 措施是IT有效的利用EXCEL等函式功能,進行批量資料的比對,也取得了比較好的效果。在專案運作當中,我們更多的做法是IT的高度參與,難題由IT 解,薄弱環節由IT幫扶,混亂操作甚至由IT託管等,這是資料管理方面引申開來的,對於專案的成功值得借鑑。
再次,S集團移動商務專案風險管理做得很不到位。從案例看,專案的進度風險是很大的,專案實施過程也證明了這一點。本身作為高層強制性的規定專案進度要求 是專案的風險,這是建立在“假設”基礎上的,假設是專案的風險來源之一,需要在專案運作過程中不斷去分析和跟蹤。9月15日反映的統計報表與日常手工報表 發生嚴重不符,實際上也是沒有做好風險識別、風險分析和風險應對措施等方面工作。其原因分析是“上線前銷售渠道分類沒有按照標準統一的嚴格規定執行”,這 就是風險啊。
再次,S集團移動商務專案的溝通管理也需要總結。8月11日,資料採集只有一半的辦事處回覆了,而且資料不是按照標準要求提供的,反應了溝通的不到位。對 於專案不同的工作要有因地制宜的溝通方法和溝通技能,從資料採集角度看,完全可以通過正式的、書面的、模板化的要求終端進行資料收集。當專案出現了兩次進 度拖延後,9月22日,高層讓鍾劍就資料整理的困難在全國銷售會議上彙報,間接說明專案經理在溝通管理上及其被動。作為專案經理的鐘劍要建立不同級別的項 目會議,如專案例會、專案評審會議、專案進展會議、專案風險分析會議、專案決策會議等等,通過及時、有效的專題會議形式完全可以把專案溝通工作做好。另外 一個側面細節值得關注,在確定最後專案上線日期10月16日時,專案總監歐陽雪對許建國、王新水的一段話可以看出,專案的歷史溝通頻次還是不夠的。
然後,專案變更控制缺失。有個細節,10月8日,專案經理鍾劍為了調整專案上線日期,以辭去專案經理作“危險”,可見專案變更管理在S集團移動商務專案還 是沒有做到位的。對於變更需求,完全可以按照正式的變更管理流程進行。本案例也反映了專案變更管理委員會等變更決策結構還是沒有在專案中建立。作為專案經 理是“整合者”、“綜合者”,需要堅定的信念和專案流程管理經驗。從案例看來,專案經理這方面意識是比較薄弱的。
最後,S集團移動商務專案也存在很多亮點,如專案經理鍾劍的專案收尾工作還是可圈可點的,在專案成功上線兩週內,他總結了近三個月的專案問題,整理了一套 更完善的專案實施方案,體現了專案經理的綜合能力,也反映了專案管理重視歷史資訊和經驗教訓的特點。又如團隊建設方面,專案經理的最終專案上線日期變更郵 件,其中反映的國慶長假的集體加班,也包括個大區的專案人員的表現可圈可點,可見專案整體士氣不錯,專案經理功不可沒!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14780914/viewspace-536487/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理例項—— 點評專案管理
- 企業資訊化專案管理八要點(轉)專案管理
- 資訊化專案管理的原則專案管理
- 專案管理資訊化提升管理水平 (轉)專案管理
- 專案管理之風險管理案例-專案交付風險專案管理
- 資訊化為什麼需要專案管理?(轉)專案管理
- 專案管理案例研究(轉)專案管理
- Python專案開發案例(一)————學生資訊管理系統Python
- 善用時間管理 圓滿完成資訊化專案
- 資訊系統專案管理系列之四:專案可行性研究與評估專案管理
- TGPMS:中國工程專案管理資訊化的“旗艦”(轉)專案管理
- 資訊化應用專案
- 資訊系統專案管理系列之八:專案成本管理專案管理
- 如何利用資訊化手段來進行管理多個專案?
- 8Manage專案管理軟體助推企業資訊化專案管理
- 如何規避資訊化專案管理中的難題(轉)專案管理
- 世博資訊化專案監理幾點體會薦
- 資訊系統專案管理師-必背的知識點專案管理
- 專案管理要點(轉)專案管理
- 資訊系統專案管理系列之三:專案管理過程專案管理
- 資訊系統專案管理系列之五:專案整體管理專案管理
- 資訊系統專案管理系列之六:專案範圍管理專案管理
- 資訊系統專案管理系列之九:專案質量管理專案管理
- 資訊化專案抗癌9法
- 資訊化專案的選題
- 專案管理:中小企業資訊化的路徑與策略 (轉)專案管理
- 《軟體專案管理應用》書評專案管理
- 資訊系統專案管理系列之十:專案人力資源管理專案管理
- 國內外值得推薦的專案管理系統排行和點評專案管理
- 專案管理8要點(轉)專案管理
- 專案管理8要點 (轉)專案管理
- 專案管理八要點(轉)專案管理
- 研發專案管理點滴專案管理
- OceanBase 金融專案最佳化案例
- 總承包專案管理——專案管理的國際化之路(轉)專案管理
- 打破專案管理中的資訊孤島專案管理
- 專案管理資訊系統(PMIS)(轉)專案管理
- 管理資訊系統開發的專案管理(轉)專案管理