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部門、業務部門和承建方三方互相妥協。系統越復雜越是這樣，企業要抓大放小，實現主要的功能需求、使用需乞降界面