標籤:專案管理
目前,大多數企業IT建設與管理都滯後於業務變革,更談不上引領企業發展了。對於這些企業而言,IT對企業業務的支撐或者說推動,是由業務需求到了一定程度來決定的。總的來說,企業的IT發展將取決於業務需求,而不是IT投資。
企業的常規做法是比較典型的交鑰匙工程,業務部門提需求,IT部門就去張羅方案論證並組織實施,業務部門最後驗收評價和使用,IT部門負責系統維護和更新。這樣做的結果往往是系統不好用,不適用,或者跟不上業務的發展,業務部門不願意用,最終成為擺設,浪費了投資,而帶來的唯一好處可能是給企業相關人員上了一堂生動現實的使用者培訓課,花錢買了經驗教訓。
一般地,在IT項目上線前後,都會做需求調研,並要求業務相關方簽字進行需求確認。而在後續的項目推進過程中,一般都會凍結業務需求不做變更響應。這樣會造成系統上線後與業務需求匹配存在偏差,需求實現程度又直接關係到項目效果,業務使用者要求更改,這又增加系統正式上線時間,影響項目如期驗收,IT部門將被詬病。如果項目比較複雜,IT部門害怕出錯,前期需求調研時間都比較長,應用推出的周期相應增加,業務部門等待時間過長,滿意度也會降低。
因此,為了推進企業IT建設,適應業務管理需要,必須讓業務部門深度參與IT建設,充分啟用業務人員的主觀能動性。如果企業以前沒有採用這種模式,可以選擇一兩個業務部門,試驗推行一些節省人力、改善效率的系統,業務部門很快感受到技術的好處,就會帶動其他部門逐漸形成主動提出各種需求的習慣。
在IT系統建設和完善過程中,企業都需要積極地管理業務使用者的需求,並根據情形對系統進行最佳化完善。為此,IT部門具有IT項目建設管理、系統維護職能,需要在系統全生命週期中對業務需求進行有效地管理,便顯得尤為重要。
一是嘗試逐步建立需求量化管理員模式,可以從使用角度對需求管理、IT實現程度、業務期望值等方面進行量化,考量項目是否滿足業務的期望。以需求管理為例,在開始建立IT系統時,可同步建立使用者的使用日誌,讓管理層、業務層的每一個使用者都可隨時瞭解企業整體系統的使用方式,哪些系統使用的頻率更高,哪些功能用的多,哪些功能用的少等。通過這樣不斷的積累,在企業內部形成這樣一種新觀念:一個系統用得好不好,首先源於業務部門的需求提得好不好,業務部門應該對這些需求負責。如果業務部門提出一項需求,但實際上並不使用這些功能,說明當初的需求提得並不好。
隨著來自業務的需求越來越多,可以進一步引入看板管理,將需求進行分級分類。需求分為功能需求、介面需求、使用需求等,主要的、重要的需求會被寫到看板上,讓所有人都可以看到哪些需求正在排隊,哪些需求正在解決中,哪些需求已經解決完畢,盡量做到公開、透明,能夠獲得相關部門和人員的理解、支援與配合。
二是IT部門要協助業務部門更好地提出需求。通過建立良好的溝通模式,IT部門和業務部門共同研究業務變化、需求變更,並深入探討需求的合理性。IT部門在接到一項需求後,並不馬上就投入需求實現的工作中,而是先對需求進行初始化,探究需求背後的動機,瞭解業務部門的真正想法、管理者的想法、技術人員的想法,各方達成一致。在確定需求的內容合理之後,才會開始進行規劃和執行階段。
對於IT部門和乙方而言,平時最頭疼的並非項目型需求,而是來自使用者平時的零散需求,或者根本說不清需求,只有一個大概的需求架構。先說前者,零散需求往往來自對現有某一項功能的改進,或者臨時需要對一部分資料進行處理等。面對這些零散需求,一般企業的IT部門會採取拖延戰術,儘可能不做響應,其實更好的做法則是擁抱需求,擁抱變更。一個好的系統是設計出來的,一個好的系統也是用出來的。一個系統在使用者的使用中,必然因為使用者的習慣和業務變化,產生各種需求,而IT部門通過小修小補的多次改變,才能逐漸讓系統變得友好易用。反之,如果一個系統不做任何變更,使用者逐漸便不願意使用,系統也就荒廢了。
至於後者,在業務需求不清晰的情況下,可以暫緩執行需求,應和業務部門繼續研究完善。當然,如果有能力,可以先搭建一些原型系統,引導業務部門思考,不斷參與系統試用,進一步明確、完善需求。
三是要加強IT部門自身的團隊建設。在項目建設過程中,IT團隊最好能夠相對固定,並且要隨著業務發展進行轉型。企業IT部門在進行專案管理時,在乙方人員進場後,不能只當“包工頭”監督乙方的工作進度,還要領會業務的IT需求和實施方案,進行需求的匹配分析。系統一旦上線,IT團隊還是不知道內部的設計細節。基於此,IT團隊需要具備更高的技術技能,包括把控需求、設計主要的技術路徑,從長遠來看更有利於IT團隊能力和價值的塑造。
根據個人經驗,IT系統建設都是不斷的折衷,IT部門、業務部門和承建方三方相互妥協。系統越複雜越是這樣,企業要抓大放小,實現主要的功能需求、使用需求和介面需求,一些未盡需求只要不影響大局也可以留待後續升級更新中去實現。從這點來看,IT系統項目建設和新房裝修其實差不多,業主方的能力強、考慮問題全面,留的遺憾就會少一些,或者無關痛癢,總體上來說就算是比較成功的了。
本文出自 “天高任鳥飛,海闊憑魚躍” 部落格,請務必保留此出處http://xjlegend.blog.51cto.com/59163/1600642
IT實施過程中如何管理業務需求