8步共振項目管理體系(7):項目實施過程的基本規範

管理信息系統項目實施過程的基本規範javascript

 

 

上兩個章節分別從組織及管理制度、企業及團隊文化的角度論述了管理信息系統供應商在實施管理上的內部整合問題,從本文開始的兩個章節則開始講述與之對應的實施管理的另外一個課題:操做,即項目實施過程當中的實施規範和方法論。html

項目實施過程當中爲何在必定要強調要有個實施規範呢?其根本用意在於:java

l  經過實施規範的推行,規矩規範實施顧問、項目經理及客戶的實施活動,保障項目活動運行的正確方向;數據庫

l  在實施過程當中爲實施顧問和項目經理提供諸如需求調研、操做手冊、數據準備、活動組織、階段確認等標準化工具文檔,以節省準備時間,下降具體項目組的工做強度,方便項目實施;網絡

l  向客戶代表,咱們作項目管理和實施是有方式講方法的,不是隨意想到哪就作到哪的,是正規軍,不是還鄉團。一方面輔助創建客戶對實施團隊的信心,二是有助於贏得客戶對實施隊伍的尊重。數據庫設計

 

本節重點介紹8步共振項目管理體系的基本實施規範,這也是整個實施項目管理體系的核心所在。工具

首先,共振的概念來源於當代供應鏈管理的運營模型,以及物理學中的振動理論。筆者在管理信息系統的諮詢與項目實踐中,強調企業內外部資源網絡的優化和集成,推崇相對集中統一的運營調度模式。只有這樣,企業的整個資源網絡纔可能實現統一的心臟跳動,整個系統的優點、能量才能達到最大,整個鏈條的運作效果才能達到最佳。佈局

以此爲基本參照點,本實施規範也強調在項目實施管理中要創建與客戶、客戶的客戶、客戶的供應商(特別是須要進行集成的其它信息系統供應商)、公司內部的關聯部門、關聯團隊特別是項目團隊成員之間的協同工做關係,協同、互動、共振、雙贏,是整個實施規範的最終實現目標。性能

進一步,可從四個方面對共振鏈實施規範的實施方法論和價值觀作出闡釋:測試

l  診斷、分析、模擬、優化,體現客戶價值

信息系統價值的體現,首先在於在先進管理理論、業界內最佳實踐和先進技術應用的基礎上,對客戶的業務模式與操做流程進行診斷分析、提供業務流程改進建議、模擬優化業務流程並對之進行調整。這也是共振鏈實施規範的客戶價值體現。

   

l  原型、規範、評審、分步,細化實施步驟

本實施規範的一大特色就是對系統原型、功能規範、實施路線的嚴格分析和確認。同時,有效地階段評審和分步實施也是項目成功前進的根本保證,而實施過程的階段性發動則是保證項目週期性活力的基本方略。

   

l  質量、進度、成本、控制,綜合三角平衡

項目管理的關鍵是在保證項目利益相關方(如客戶、公司、項目組等)都恰當滿意的前提下來實現質量、進度、成本的綜合平衡和控制。這其中任何一角的偏執追逐都會致使總體三角的失衡,所謂的以最小的成本、最少的時間來實現最高的質量,只能理解爲一種理想和偏執,在實際中每每致使做繭自縛,把項目實施活動演變爲一種災難歷程和痛苦回憶。

   

l  責任、協同、共振、雙贏,協做戰略實現

責任是協同的前提。責任的明確劃分不是要豎立彼此之間的責任壁壘,而是爲了理清各自的職權,由此再來明確你們該在什麼地方協同,如何協同。責任不清,職權不明是協同不順暢的基本根源。只有在明確職責基礎上的協同互動,才能實現合做多方的共振、雙贏,這也是整個實施規範的最終實現目標。

 

最後,按客戶項目生命週期的完整定義,實施過程只屬於其項目的中後階段。實際實施階段的劃分則以雙方的聯合啓動爲起點,以項目驗收轉入維護期爲終點,參照其中的重大階段評審點和階段發動點,把整個實施過程分爲8大階段,它們是:項目啓動、調研分析、開發測試、實施啓動、系統培訓、上線準備、系統上線、驗收維護。這8個階段自己呈現滾動性交叉,某些步驟按實施路線圖還能夠重複屢次。

以上是對8步共振實施規範的概念性介紹,其核心在於把握實施過程當中的關鍵點。因爲篇幅所限,本文在下面僅對這8個階段作策略性的介紹。

 

1.1.     項目啓動

項目啓動,通常以合同雙方簽定正式合同爲起點(也有以甲方支付首款或乙方顧問進場爲標誌的),以項目啓動大會的召開爲終點,是整個實施過程的第一關鍵點。其主要活動包括:創建項目組織、肯定基本項目計劃、實施範圍,並召開啓動大會。

項目啓動,從整個項目管理上看,實際上是企業對具體項目的整合,這包含:資源的整合、組織的整合和理念的整合;從人的角度,就是如何選擇正確的人,去正確的作事。

對實施顧問團隊而言,在這一階段的關鍵性工做包括:

l  向客戶介紹公司的實施理念、實施規範和方法論;

l  協助客戶肯定對方的項目組織結構,即項目領導組、實施管理組、職能組、IT組和監管組的人員構成,肯定項目決策和監管機制,肯定項目管理的規則和制度;

l  按照當前對客戶狀況的基本瞭解,參考項目合同,與客戶的實施管理項目組肯定大體的實施階段計劃、實施範圍;

l  明確項目第二階段,即調研分析的組織形式及細節到責任人天的工做計劃;

l  協助客戶項目管理組組織準備項目啓動大會,必要時協調公司的高級管理人員到場致辭宣講。

 

項目啓動大會,看似形式,實際上是企業全部相關資源的整合宣告:明確合做雙方,特別是客戶方的全部項目人員都要爲項目目標的實現前進,號令全部人員都要遵照項目的規則,明確各自的職責和考覈體制,積極主動地配合項目實施。或者說,項目啓動大會,是整個項目佈局立勢,建規則立規矩、樹立雙方實施管理團隊威嚴和地位、掃清實施過程組織障礙的關鍵時刻。有醜話必定要說在前面,若是你們開始時就不嚴肅,之後就難以再嚴肅起來了。

對項目顧問團隊,項目啓動是個尤爲關鍵的階段。在雙方實施團隊的初始接觸過程當中,經過顧問人員的待人接物,言行舉止,特別是講解實施規範及理念,溝通項目計劃,肯定項目組織的過程當中體現的專業水準,讓對方感受實施顧問,特別是項目經理真正是有水平,夠道行,象個專家。從而得到客戶對顧問團隊的承認,在心理上創建至少平等甚至相對優點的地位。不然若是一開始就讓客戶對你不信服,向實施項目組的上級部門甚至公司喊着嚷着要換項目經理,換顧問,使得項目剛一開始就進入危機時刻,麻煩就大了。。。

 

1.2.     調研分析

調研分析,是整個實施過程的第二關鍵點。在這一過程當中,雙方項目組按照前一階段肯定的調研計劃,由客戶實施管理組組織協調,實施顧問組主導執行,主要活動包括:

l  業務現狀調研。瞭解實際用戶的業務流程,掌握其當前最爲迫切須要解決的需求和問題。若有可能,可同步分析介紹系統實現的流程和方式;

l  IT現狀調研。瞭解客戶軟硬件及網絡的建設狀況,瞭解當前信息系統的應用狀況和優缺點。作爲替代系統,新系統該如何揚長避短;做爲集成系統,系統間如何實現信息交互。必要時須要提請組織與其它需集成的信息系統供應商的接口會談;

l  客戶高層領導訪談。簡要彙報調研狀況,重點是從客戶高層的角度把握信息系統的實現目標和願景。實施項目經理要有意識地努力創建與客戶高層的溝通渠道,一方面要注意方式與分寸,另外一方面也切不可羞羞答答,縮手縮腳;

l  在實施雙方完成現狀與需求調研,並確認調研成果的基礎上(通常在調研後期搞個現狀調研報告會,提交調研文檔便可),綜合客戶的實際狀況、迫切程度以及領導意圖,討論並建議項目的實施規劃路線圖,即項目的總體實施範圍、須要劃分爲哪幾個階段部署、每一個階段要實施哪些系統模塊;對應地各階段要實施哪些部門或區域公司、須要作哪些提早準備等。這也是制定後期詳細計劃的基本依據;

l  實施項目經理和顧問團隊,整理系統配置清單、二次開發清單和相關的需求分析報告。而後協同公司主體研發團隊,介紹並討論需求,劃分哪些功能開發放在研發團隊,那些功能由項目組本身組織實現,並肯定開發進度。最後,應PMO的要求,整理並提交系統功能規範、實施路線圖和項目計劃,組織項目階段評審,並按評審意見整理改進;

l  項目經理向客戶提交系統功能規範、實施路線圖、詳細項目計劃、軟件系統配置要求及硬件網絡建議清單,客戶項目組組織內部討論,並反饋用戶意見和建議,雙方協同溝通調整。最後上報客戶項目領導組作審批確認,項目階段工做完成。實施項目經理再按肯定後的結果,調整實施計劃與預算,提交職能部門及PMO批准執行。

 

客戶現狀和需求的調研,是項目的關鍵過程,每每須要必定次數的反覆,於是須要愈加關注調研的方式和方法。本文在這裏列舉的主要有:問卷法、訪談法、投影法、白板法、差別法和原型法,實際中可視狀況多種方法並用。

l  問卷法。即調研前事先發布標準調研問卷給調研對象。這個方法通常只是作爲其它方法的輔助工具,起到引導啓發用戶思惟的做用,除非公式化的肯定答案,通常都不能簡單收集回來就算調研完成了。調研問卷的主要內容包括:組織結構、人員職責、正常及異常工做流程、往來單據、IT現狀、人員現狀、當前系統的優缺點、最迫切須要解決的問題(通常提3個);

l  白板法。現代溝通管理中每每強調你們要面對面,要關注彼此的表情,眼神,手勢等。但筆者仍是強調調研溝通的過程當中要有一個溝通的載體或平臺,從而避免你們老是大眼對小眼,避免某些沒必要要的「尷尬」。這其中最簡單的解決方法就是搞一塊白板,由實施顧問引導用戶把流程和問題都寫到白板上,經過文字化表達,你們都能一目瞭然。用該方法能夠直接在白板上勾畫出用戶的操做角色和流程,甚至可造成具體功能點的基本原型;

l  投影法。與白板法相似,只不過是要利用電腦,白板換成了投影儀;

l  差別法。用於存在標準化產品時。溝通雙方可直接對照系統流程進行演示並對答問題,從而可以讓用戶快速地瞭解系統的大概功能,並肯定之間的差別點。人少時能夠不用投影;

l  訪談法。這是一個通用方法,特別是在企業高層領導訪談時。實際執行中,問方人員要作責任分工,確認由誰主要負責提問,由誰主要負責記錄,避免談話的斷斷續續、互相搶話,引導客戶能暢所欲言。訪談過程當中通常不建議錄音,這是由於錄音一是容易使訪談對象感受到壓抑,二是錄下的東東每每根本無暇整理;

l  原型法。這是另一種溝通的載體。特別是當某些功能總體空白或功能相對重要時,強烈建議能快速構建出一個系統原型,你們在原型的基礎上再展開討論,一是避免雙方直接空對空地直白,二是避免理解上出現重大誤差。

 

另外,系統功能規範,也就是項目的驗收規範,明肯定義了項目的輪廓和範圍,這每每也是容易被有意或無心忽略的地方。客戶在項目開始的時候每每只注意他本身的關注點,但這個系統最後要長成什麼樣子,有哪些明細的功能,通常沒有個明確的概念,有時甚至故意裝糊塗。最後,每每也由於驗收標準的模糊,缺乏一個基本的依據判斷項目大概到什麼程度就能夠啓動驗收了,結果成了你們爭執的癥結點。實施項目經理和顧問團隊都要牢固樹立一個觀念:項目一旦啓動開始,你們的一切活動就是奔驗收而去,一切都是爲了項目的最後驗收達成。這是個基本指導思想。

這裏沒有特別強調信息系統的初始安裝。這要看乎項目的實際,是否有標準產品,合同是否有明確要求,是不是回款階段等。

另外,調研分析過程當中,要特別注意不要過多地講述業務流程重組(BPR)而應提業務流程優化的概念,並要將現有系統做爲流程優化的原型。調研分析過程當中能夠對客戶的中高層管理者作系統管理理念和標準流程的培訓,但不是要對企業管理理論與實踐作全面探討。不然,還不如建議用戶先上個諮詢項目。

 

1.3.     開發測試

實施參與方在完成系統功能規範確認後,實施顧問組針對二次開發功能表和需求分析表,就須要啓動系統的開發測試任務了。在這個過程當中,實施顧問團隊須要和本身的職能部門、公司的研發團隊協商,精細工做任務分解和資源分配,並具體各部分的工做計劃。具體的工做定義包括:

l  哪些開發任務屬於公共核心功能或有共性的重大功能,須要由研發團隊實現;

l  哪些開發任務屬於共性功能,但因爲研發本身的人力和計劃緣由,須要項目組本身先行實現,研發團隊給予必定指導;

l  哪些開發任務其它項目組已經部分或所有實現,本項目組可予以借鑑和繼承;

l  哪些開發任務須要實施項目本身實現,必要時還要啓動外包流程。

ERP系統是多業務、財務模塊的集成,有可能牽一髮而動全身,在公司研發體制下更可能涉及多個團隊和人員的協同工做。所以,對系統的開發、調整及測試必定要遵照必定的規範,須要創建統一的代碼管理、開發管理、文檔管理和測試管理平臺。對各個開發階段如:需求分析、系統設計、數據庫設計、單元開發、集成測試、試驗發佈等都須要內部的階段性評審,必要時甚至可邀請客戶項目組核心人員參加,以便及時發現問題,減小反覆,提升效率。

同時,要求測試用例數據要儘量使用客戶的實際採集數據,保證規則規範,這也是整個過程都要貫徹注意的地方

若是須要多系統集成,須要留出單獨的時間與其它系統供應商進行系統聯調。同時,爲保持客戶的協同工做,在條件容許時,可發佈系統的Beta版本到公司或用戶的演示環境,由客戶實施項目組協助對系統流程、界面和操做進行試用,顧問組根據試用意見及時作出系統調整。

與此同步,項目經理和應用顧問,結合公司的標準文檔和用戶實際,制定系統標準維護手冊,起草標準操做流程,即SOP.

 

1.4.     實施啓動

當系統Beta版本發佈測試,功能逐步趨向穩定後,實施項目經理和應用顧問就要協調客戶項目開始實施啓動的準備工做。

一個項目,爲何會有兩次啓動呢?對比項目啓動,實施啓動的主要活動和功效爲:

l  肯定並準備培訓環境,安裝測試系統,確認並維護培訓及測試用的數據用例;

l  雙方項目組對照系統功能規範,簡要遍歷並測試信息系統的完整性和有效性。該步驟雖不是對信息系統的最後接收確認,但對客戶項目組而言,必定要作到心中有數。若是發現重大的執行誤差,須要作及時溝通確認,後續的全部實施計劃都要作相應調整。以此,也反映出對雙方在開發測試過程當中協同互動的重要性;

l  在基本確認系統功能的基礎上,協做雙方對後續的培訓計劃、數據準備計劃進行溝通確認,滾動後期實施計劃;對各部門的操做角色、關鍵用戶、參訓人數進行確認;下發用戶操做手冊和第一版SOP;

l  項目啓動,可看作是出征前的總動員;實施啓動,則是衝鋒的號角吹響。經過全部項目人員參與的實施啓動大會,對因爲開發測試的間歇致使的垂落士氣進行再次激勵,對具體實施方法、實施紀律再次明確宣告,「革命終於要真正開始了。。。」

l  分業務部門召開靜態數據準備培訓會,下發數據準備模版。該步驟視用戶的信息基礎狀況而定,必要時可提早到功能規範確認會後,則此時就成了數據準備的檢查。

 

1.5.     系統培訓

實施啓動後立刻要執行的工做就是系統培訓,這也是信息系統知識轉移的關鍵過程,也是實際用戶對系統進行模擬測試的第一個正式階段。系統培訓的基本要求爲:

l  嚴格培訓計劃和組織,明確培訓考覈和獎懲制度;

l  以集中培訓爲主,以基於角色和運用場景的形式,重點在於培訓相關部門的關鍵用戶,培養系統運用的骨幹力量

l  培訓儘量採用用戶的習慣用語和模擬數據。不要使用對操做用戶而言過於生僻的專業術語,以方便你們在培訓中創建共同語言,確保溝通的有效性;同時,要注重模擬數據的嚴肅性,不可過於離譜和生活化,讓用戶感受如同兒戲;

l  培訓中採用管理理念講解和實際操做相結合的形式。固然,對具體做業人員,理念性的東西不是一天兩天就能貫通的,但至少要讓他們知道那些業務流程是能夠直接作的,哪些流程是不能直接作的,對不清楚的流程必定要問清楚了才能去操做,而不能按本身之前的經驗隨意而爲;

l  培訓過程當中要配合以用戶操做手冊和標準操做流程。對實際用戶而言,最迫切的事情是他手頭的實際業務該如何操做,報表該如何反映,數據如何獲取。這就要求必定要有個標準操做流程指引,即SOP. 實際項目運作中,這是每每容易被實施團隊忽略的地方,最後致使什麼問題都要靠顧問的兩張嘴去解釋。更有甚者,有的公司和實施團隊還奢望讓用戶本身主導去寫操做手冊,這樣的質量和進度切不說,每每還所以引起用戶的很大不滿和爭議。

 

系統培訓的最後就是培訓考覈與培訓總結。同培訓同樣,考覈也要分角色進行,對不一樣的角色的考覈點不徹底相同,並且要求重考者的考試難度要大於初考者。對考覈不合格者,最直接和最有效的處罰就是禁開系統賬戶。

另外,對培訓過程當中用戶反映的實際系統問題,實施顧問團隊要能快速反應,對關鍵問題要及時修正解決,保證培訓過程的正常進行。

 

1.6.     上線準備

在系統培訓及考覈結束後,合做雙方總結確認系統培訓的成果、遺漏問題的解決思路和計劃後,項目就進入上線準備階段。

    上線準備,其核心就是對項目作上線前的最後評估,肯定系統的標準業務流程和最終上線計劃。該過程當中的主要活動包括:

l  系統小規模試運行。這是實際用戶對系統進行模擬測試的第二個正式階段,是系統UAT(用戶接收測試)的基本表現形式,也是整個系統正式上線前的合成演練。

系統小規模運行,不一樣於系統培訓階段的分部門、分角色的相對獨立性測試,是對整個系統邏輯和流程的全面模擬。實際操做中,雙方項目組要精心選擇並設計測試用例,並配合必定數量的實際執行單據,儘量演繹出系統的主線和主流程。而後,組織全部項目人員按照實際工做流程正式模擬執行。項目組在現場及時指導,跟進並解決運行中出現的問題,整個階段最長通常不超過一個月。

    具體項目中,客戶可能原來就已經有相關的業務系統,也可能仍是在採用部分或所有手工作帳的形式。實際運作中,也存在兩種可能的上線模式:全系統試運行並行上線,或者是直接執行系統切換上線,但這都不是本實施體系所推薦的實施方式:

   

   首先,長時間的系統全面並行會產生一系列問題,極可能會給項目實施帶來很大困擾,甚至是全面災難與噩夢。一方面,系統並行意味着兩個系統間要作大量的數據對比,而徹底的吻合將是很是困難而消耗精力的。這些差別多是因爲系統自己處理方式的差別,也多是因爲系統操做的錯誤(在上線初期,這又是很難徹底避免的),調整不一樣處理方式及查找錯誤操做形成的差別,以肯定系統的正確性將是很是耗時費力的。最後的結局極可能是你們誰都不知道到底那個系統是正確的,哪一個都不可信,系統並行最後變成了決策的僵局。另外一方面,系統並行將使用戶要同時處理兩次相同的業務,若是再加上要處理之間的差別,工做量之大實在不能以簡單倍數計增。

其次,與之相反,若是不經系統性模擬與實際運用,而直接執行系統切換,實際上線的時候,極可能會暴漏出一大堆問題,引發用戶上上下下一大堆抱怨,嚴重影響上線的效果和評價。

 

 項目需求回顧。通過實施啓動時的簡要遍歷、系統培訓時的獨立模擬、及如今的小規模試運行,系統的流程、功效基本獲得明確,問題也獲得有效展漏。雙方項目組經過對項目需求進行認真回顧,反省項目需求的變化,肯定項目目標的誤差,總結項目控制的成效,並進行相應的調整。必要時,須要報請需求變動流程。

 

l  肯定標準業務流程手冊。在實施啓動階段已經發布了SOP的初稿。經過系統培訓和上線準備階段的模擬測試,實施項目組應將這些新業務流程和系統管理流程進行整理、完善,造成公司正式的《標準業務流程手冊》,提交公司負責人審覈、簽署,而後在全公司範圍內發佈,做爲運做信息系統的指導書。

 

l  系統接收確認。雙方項目組在對系統進行的上述模擬測試完成後,參考系統功能規範書,遍歷信息系統的最後版本,共同確認系統功能對需求的符合性,最後由客戶項目負責人簽署系統接收確認書。

 

l  系統上線評估。系統接收確認後,標誌系統上線前的準備工做均已完成,須要對前期的全部工做進行全面的回顧和檢查,對系統是否能夠上線作最後評估。

 

l  最終上線計劃肯定。上線評估確認後,項目進入上線準備階段的最後工做:肯定最終上線計劃,具體包括靜態數據檢查與維護計劃、動態數據準備與培訓計劃、實際環境安裝計劃、系統基礎配置維護計劃、初始數據導入計劃等。若有用戶部門提出補充培訓需求,還須要安排對最終用戶的培訓計劃。與以前的系統培訓不一樣的是,這個培訓主要以客戶項目組來主導完成,實施顧問組負責輔助性輔導。

    

    因爲上線過程的複雜性,爲保證上線的進程和質量,增強過程的有效控制,上線計劃的制定要知足必定的要求,如:上線計劃必定明細到天、落實到具體責任人、規定工做截止時間、考慮可能的資源約束、預留緩衝時間以應對異常狀況等。

    

    項目上線計劃的制定,須要協調多個部門及衆多人員的活動,意見衝突通常不可避免,實施顧問組須要配合客戶項目組作大量的溝通協調工做,儘量地一致化你們的意見和行動。若是多方意見最後實在不可協調,須要報告客戶實施領導組作最後仲裁,並獲得實施領導組的最後批准。

 

1.7.     系統上線

項目上線,是整個實施過程的第三關鍵點,也是項目投產的重要標誌,要求必須作到「首戰必勝」。其主要活動包括:靜態數據檢查、動態數據準備、實際環境安裝、基礎系統配置、最終數據導入、實際系統運行和系統上線確認。

其中,靜態數據和基礎配置(系統參數、角色、權限等)的設置要求在前期的模擬中已經屢次進行確認和驗證,這裏的工做主要是進行最後的檢查並按必定的方式(手工錄入或工具導入)維護進系統。這樣,整個上線過程的關鍵工做就是動態數據準備、系統上線切換和系統上線的確認。

動態數據準備,直接關係到系統初始數據的準確程度和項目上線的最終效果。在全手工或部分手工的環境中,用戶各部門提供的同一種動態數據的可能會互不一致,如財務、採購、物控各是一套(這實在是件使人萬分挫敗的事情)。如此就要求雙方項目組積極協調各部門對同一數據進行有效覈對,歸口到一個部門進行對應數據的最後統籌,關聯部門最後要統一數據標準並對提交數據的準確性負責。

系統切換並開始執行實際業務後,系統上線正式開始。等系統基本運行平穩後(涉及財務系統時,通常須要一個正常會計期間結束;不涉及財務系統時,業務單據正常流轉後便可),標誌一個重要的里程碑達成,顧問項目經理要及時督促客戶項目負責人簽署項目上線確認書,確認上線的正式完成。固然,上線確認不等於項目的最後成功確認。實施顧問組還須要配合客戶項目組對系統的運行狀況進行跟蹤,及時解答用戶在實際工做中碰到的問題,保障系統的平穩運行。

 

1.8.     驗收維護

    系統上線確認並穩定運行一段時間後(通常按合做雙方的合同約定),顧問項目經理須要積極協調客戶項目組完成項目驗收,這也是項目活動的最後關鍵點。項目驗收,通常以驗收大會爲表現形式,但驗收實質上是一個過程,而不是一個單純的點。

    項目驗收,關係到對項目的最終評價、合做雙方的根本利益體現以及後續的工做方式,對雙方來講都是慎而又慎的事情。雖然你們有系統功能規範書的基本約束,但實際項目老是充滿不少不肯定性,信息系統的功能與性能、服務商的實施過程組織未必都能作到盡善盡美,客戶的需求也常常可能變動,致使雙方在進度、費用、質量上的扯皮現象常常發生,整個項目最後經常是上而不驗,驗而不收。

    對此,要求顧問團隊,特別是項目經理要對整個項目的狀態,特別是客戶項目負責人的態度有着清晰的把握,一方面要積極響應客戶的需求,協調問題解決,不能動輒以「超出功能規範」爲藉口直接回絕;另外一方面要積極推進驗收進程,必要時須要協調本身的上層主管、銷售經理等資源,從各個層次上增強對話溝通,全力確保最後驗收的達成。其中的關鍵是和客戶再次確認驗收檢查表和對應的工做計劃表,主要是要明確:

l  哪些功能你們是可讓步妥協的。對客戶,這意味着讓步接受系統當前的問題;對實施提供商,意味着妥協接受客戶的要求,對系統作無償調整;

l  哪些功能可作爲待解決問題放到驗收後解決,即帶着問題驗收,不讓對應問題成爲項目驗收的障礙;

l  哪些功能你們可明確放到下一期解決,即明確問題與本項目驗收無關,雙方再單獨協商補充合同或協議,放到另一個實施過程裏解決。

    項目驗收,以客戶項目負責人最終簽署項目驗收報告爲確認形式。與實施顧問團隊對口的PMO在接收到客戶的項目驗收報告和財務部門的回款通知後,配合項目經理執行項目的評估和決算流程,對項目的實施服務、進度、費用、質量進行評估和總結;按公司規定收集所有知識產權;按實施制度提請落實對項目組的最後獎懲。

    另外,項目驗收確認後,除了繼續要對驗收遺漏的待解決問題繼續處理外,項目總體上進入支持維護階段。系統實施商要根據合同中定義的服務支持條款,經過本身的支持服務體系,協調客戶方常設的系統運管組,對客戶提供相應的無償及有償服務。客戶關係將會繼續持續,並進入到下一個流程。

 

    以上,是對本項目管理體系的核心:信息系統項目實施過程的8個步驟的策略性介紹。其中每個階段,特別是開發測試到驗收維護階段,按照實際項目的實施階段路線圖,均可能會進行屢次。這8個步驟,也不是嚴格地串行排列,某些細節步驟徹底能夠並行執行,實際項目中可靈活運用。在實施方略綜合中還會對此展開說明。

 
 

分享到:新浪微博騰訊微博人人網開心網 更多0

查閱更多相關主題的帖子:  實施規範  方法論  系統功能規範  實施路線圖  白板法  差別法  原型法  SOP
 
收藏 (1) |  舉報 | 閱讀(5308) |  (10) |   回覆(10) |   查看MiWei的我的檔案
 

評論

 

因近兩週的特別工做安排,沒能抽出不少時間對本實施體系最關鍵的環節:基本實施規範進行最後整理,致使本連載一度中斷。如今,本連載還剩下輔助實施規範、實施經驗雜談、實施方略綜合、根本總結與後記四個章節,內容原已基本完成,爭取本週把所有內容發佈。多謝你們!

相關文章
相關標籤/搜索