什么是需求建議書RFP

1、需求建議書(RequestForProposal,RFP)什么是需求建議書需求建議書是指從客戶角度出發(fā)，全面、詳細地向服務商陳述、表達為了滿足其已識別需求所應做的準備工作。也就是說，需求建議書是客戶向服務商發(fā)出的用來說明如何滿足其已識別需求的建議書，是客戶與服務商建立正式聯(lián)系的第一份書面文件，又稱招標書。需求建議書一般由客戶起草，主要描述客戶的需求、條件及對項目任務的具體要求。一份完整的需求建議書主要包括滿足其需求的項目的工作自述、對項目的要求、期望的項目目標、客戶供應條款、付款方式、契約形式、項目時間、項目申請書的要求等。好的需求建議書能讓服務商準確把握客戶所期待的產(chǎn)品或服務。當然，并非在所

2、有情況下都需要準備一份正式的需求建議書，當某一企業(yè)的需求由內(nèi)部開發(fā)項目予以滿足時，這一過程似乎變得簡單多了，此時更多需要的是口頭上的交流和信息傳遞，而不是把寶貴的時間耽擱在僅僅起到信息傳遞作用的需求建議書上。例如，某一軟件開發(fā)公司感到公司原來的財務分析系統(tǒng)已經(jīng)遠遠不能適應日益增加的業(yè)務需要時，便可直接要求軟件開發(fā)小組進行開發(fā)，這時只需口頭把相關的要求傳達給軟件開發(fā)小組即可。需求建議書的書寫要求書寫RFP要認真負責、嚴肅對待，內(nèi)容要具體，語言要精練1 .在第一行正中寫"建議書"三個字。2 .寫接受建議對方的名稱。3 .正文：(1)建議的原因或出發(fā)點，便于對方考慮。(2)建議的

3、具體事項。4 .表達建議者的愿望。5 .結(jié)尾寫表示敬意的話，如"此致敬禮"等語。6 .寫上建議者的名稱和寫建議書的日期。需求建議書的結(jié)構(gòu)和格式1、標題2、稱謂3、正文(開頭部分，主體部分，結(jié)尾部分)4、署名及時間需求建議書的書寫指導方針需求建議書必須說明項目目標(projectobjective)或目的，包括任何可能對承約商有用的合理信息或背景信息，以便承約商可以準備相應的建議書。對外起草一份正式的需求建議書，有如下的指導方針：(1)需求建議書必須提供工作陳述(statementofwork,SOW)(2)需求建議書中必須包含客戶要求(customerrequirement

4、s)定義好規(guī)格和屬性。(3)需求建議書中應當說明客戶期望承約商或者項目團隊提供什么樣的交付物。(4)需求建議書中應當列明任何應由客戶提供的物品。(5)需求建議書中可能要說明需要客戶審批的內(nèi)容。(6)某些需求建議書中會提到顧客想用的合同類型。(7)需求建議書可能會表明顧客想用的付款方式。(8)需求建議書應當表明項目完成所要求的進度計劃。(9)需求建議書應當指導并說明承約商申請書的格式和內(nèi)容。(10)需求建議書應當指出客戶希望潛在承約商提交申請書的最后期限。(11)需求建議書可能會包含評價標準。需求建議書的主要內(nèi)容需求建議書一般包含以下主要內(nèi)容：客戶必須搜集大量相關資料準備需求建議書，因為IT項目

5、實施者需要按照RFP來準備他們的項目技術方案，并以此參與競標。RFP中包括項目的目標，也就是用戶的期望，也包括客戶要求項目的進度計劃；對實施商申請書的表格和內(nèi)容的規(guī)定；客戶希望潛在的實施商提交投標申請書的最后期限；評價申請書的標準等。一份好的RFP應該包括以下一些內(nèi)容。1 .工作表述工作表述就是說明項目的工作范圍，概括客戶要求開發(fā)商或項目團隊執(zhí)行的任務或工作單元，說明項目所涉及的各種事情，哪些必須由開發(fā)商或項目團隊去完成，哪些由客戶自己去做。例如，一個辦公自動化軟件系統(tǒng)的具體目標。又如建設一個網(wǎng)站，所需設備的采購任務，是由客戶自己完成，還是由開發(fā)商去完成；企業(yè)網(wǎng)站上的頁面文字，是客戶自己撰寫，

6、還是由開發(fā)商撰寫等。2 .任務要求需求建議書必須要具體規(guī)定開發(fā)商需要完成任務的規(guī)格和特征，如要求涉及大小、數(shù)量、顏色、重量、速度和其他開發(fā)商提出的解決方案中，所必須滿足的物理參數(shù)和操作參數(shù)。例如，建立一個企業(yè)網(wǎng)站，可能要求在1000人同時訪問的情況下不會產(chǎn)生堵塞的感覺，網(wǎng)站的瀏覽頁面不低于多少；建立一個自動結(jié)賬和收款系統(tǒng)，可能要求每天能辦理12000次交易的功能和其他特定的功能，如在開出了發(fā)票的30天內(nèi)沒有收到賬款，就會自動產(chǎn)生催款通知。具體的任務要求，可能會成為將來的驗收標準。3 .交付物交付物就是開發(fā)商所提供的實體內(nèi)容，這在需求建議書中應該說明。例如，對于自動結(jié)賬和收款系統(tǒng)來說，客戶可能要

7、求開發(fā)商提供硬件(計算機)、軟件(磁盤和一些印刷品)、操作手冊和培訓課程。交付物也可能包括客戶要求開發(fā)商提供定期進度報告或終期報告。4 .客戶供應條款需求建議書還應該列出客戶的供應條款。例如，客戶需要建立一個網(wǎng)J站,可能需要向開發(fā)商提供企業(yè)內(nèi)部的組織結(jié)構(gòu)及各部門之間業(yè)務關系的詳細說明，包括信息流程的類型、信息流量和發(fā)生頻率等。5 .表述客戶對需求的確認需求建議書不是對客戶需求的最后確認。最后的確認應該在對開發(fā)商提出的方案進行評估之后。例如印刷宣傳手冊，可能在開印之前要經(jīng)過客戶審定；局域網(wǎng)的建設，在購買材料和設備之前，客戶必須審定開發(fā)商的技術方案。這一點在需求建議書中必須向開發(fā)商說明。6 .期望

8、的合同類型(1)合同可以按固定價格訂立。這樣，開發(fā)商實際上就是費用包干?？蛻糁唤o固定的價錢，不管開發(fā)商實際工作花費多少。開發(fā)商必須保證功能的實現(xiàn)和質(zhì)量要求，超支的風險由開發(fā)商負擔。(2)合同也可以規(guī)定開發(fā)商不承擔風險，即在時間、原材料限制的條件下，不論實際成本多少，都會給開發(fā)商特定的報酬，也就是所謂包工不包料。在我國現(xiàn)階段的條件下，由于質(zhì)量檢驗和資信度水平不高，這種合同比較普遍。在需求建議書中，最好說明客戶是希望采用那種類型的合同。7 .期望的付款方式付款方式可以分為一次性付款和分階段付款；在開始前付款和結(jié)束后付款。一般依項目的性質(zhì)來定付款方式。如網(wǎng)頁制作，往往在項目末期付款；而架設局域網(wǎng)，一

9、般在方案確認后，付款30%以便開發(fā)商采購，工程結(jié)束驗收后付滿90%,留10%等到使用一段時間以后確認無問題時付清。具體付款方式需要合同雙方協(xié)商，但在需求建議書中，客戶應該先提出自己的期望付款方式。8 .要求的進度計劃進度計劃的要求可能很粗，如要求在6個月內(nèi)完成；也可以詳細一些，如多長時間內(nèi)完成方案設計和審定，多長時間內(nèi)完成硬件選購與安裝，多長時間內(nèi)完成軟件研制、測試與安裝，最后開發(fā)商在系統(tǒng)安裝調(diào)試后，在多長時間內(nèi)提交所有的系統(tǒng)文件和操作培訓。9 .申請書的格式和內(nèi)容提示為了便于在幾個開發(fā)商之間進行比較和評價，申請書應該在形式上采取同一個格式，內(nèi)容的結(jié)構(gòu)也應該一致。這樣對不同的申請者來說比較公平

10、，也能減輕客戶在評審時的工作量?？蛻粼谛枨蠼ㄗh書中可以限定申請書的每一部分采用的文字數(shù)量或頁數(shù)。10 .提交申請書的最后期限申請書受理的截止日期是必須要交代清楚的。例如，要求開發(fā)商在接到需求建議書后多少個工作口之內(nèi)(如l周之內(nèi)、1個月之內(nèi)等)提交申請書，或大家一律在某月某日之前提交申請書。這樣做的目的是便于同時對眾多的申請者進行比較、評估，也是為了保持公正，不給某些開發(fā)商以額外的時間和機會。11 .對申請書的評價標準要告訴開發(fā)商客戶將根據(jù)哪些準則來評價他提交的申請書。這樣做的目的，是指導開發(fā)商寫好申請書。一般評價標準包括4個方面的內(nèi)容：(1)開發(fā)商在類似項目中的經(jīng)驗。如他們近期是否在預算內(nèi)按期

11、完成了類似的項目，客戶對他們是否滿意？(2)開發(fā)商提出的技術方案是否合適。如采用哪種類型的計算機軟件？數(shù)據(jù)庫的設計、方法是什么？用來建立管理信息系統(tǒng)的是哪種語言？采用哪些供應商的設備?等等。(3)進度計劃。開發(fā)商是否能按照所要求的進度完成項目計劃？(4)成本。如開發(fā)商的報價是否合理？成本預算中有無漏算的條款？將來在執(zhí)行時有沒有可能出現(xiàn)超支，或有無可能因過于節(jié)約而導致質(zhì)量不能保證？有的中請人為了爭取合同，在報價上壓低成本，到了執(zhí)行階段，或偷工減料，或增加成本，結(jié)果導致所建系統(tǒng)的缺陷很多，或使最終成本大大超出原始的估算。對此需要引起注意。12 .資金總量開發(fā)商總是希望了解客戶有多少資金可以用于發(fā)展

12、擬議中的真T項目，但客戶在需求建議書中，往往不愿意透露這個信息。其實，客戶暗示大約的數(shù)字，告訴開發(fā)商他打算花多少錢來辦這件事是有好處的，這樣可以使開發(fā)商能夠提交與資金水平相適應的申請書，提高在項目準備階段的工作效率。需求建議書的必要性需求建議書(RFP)是項目客戶與開發(fā)商建立正式聯(lián)系的第一份書面文件，也叫招標書。一般由項目的客戶自己起草，主要描述客戶的需求、條件以及對項目任務的具體要求，向可能的開發(fā)商發(fā)送。需求建議書是客戶為確保供應商理解項目的需求，并在此基礎上提供項目建議書而編制的需求規(guī)范。雖然它不能確?？蛻魮?jù)此就能獲得理想的解決方案，但卻可以幫助客戶發(fā)現(xiàn)那些盡可能接近自身需求的系統(tǒng)準備。其

13、目的是從客戶自身的角度出發(fā)，通過全面、詳細地陳述，使開發(fā)商或項目團隊理解客戶所希望的是什么，以可行的價格滿足客戶的已識別的需求。對于一些預算較少的客戶，開發(fā)商往往不愿意花精力準備正式的方案建議書，這種情況下，客戶的需求建議書就變得很重要。事實上，項目無論大小，都需要編寫需求建議書。第一，需求建議書需要描述用戶的目標與需求。編制需求建議書的過程也是客戶進一步明確自己的目標與需求的過程，并以此建立起客戶與供應商進行深人溝通的橋梁。即使因為各種原因使得供應商看不到或不愿響應需求建議書，這種努力也是值得付出的。第二，需求建議書可節(jié)省選型的時間，并使得對各供應商之間的比較變得更容易?？蛻籼峁┙o所有競標供

14、應商的信息都是一樣的，避免了跟各開發(fā)商的重復溝通，同時，有需求建議書作為基準，客戶可以約束各開發(fā)商以一致的格式提交方案建議書，以提高各供應商之間的可比性。第三，需求建議書可以避免一些潛在的疏漏。在準備需求建議書時，客戶往往會因為太過關注具體細節(jié)而忽略了一些重要的因素。收到需求建議書后，有的供應商可能會主動對這樣的疏漏提出質(zhì)疑以提醒客戶。還有些開發(fā)商為了使自己的方案建議書更具有吸引力，甚至會提出一些需求建議書沒有涉及的好想法來拓展客戶的思路。編寫需求建議書的一般原則需求建議書應該由用戶編寫，但各種客觀因素的限制，實際上很難做至上所以，很多時候都是由用戶與項目小組共同編寫。編寫項目需求說明的J過程

15、也是項目小組帶領客戶進入項目需求啟發(fā)的過程。編寫優(yōu)秀的項目需求建議書沒有公式化的方法，需要大量的實踐經(jīng)驗。以下是編寫需求建議書需要把握的幾個原則：(1)需求應該是正確的。每個需求必須精確描述要交付的功能。確定需求內(nèi)容是否正確，需要用戶的代表來參與確認，由他們檢查、決定用戶需求的正確性。沒有用戶的需求檢查就會導致很多項目實施中的問題出現(xiàn)。例如用戶會說：這不是我們要的東西"；你沒明白我們的意思”，等等。(2)需求應該是可行的。項目的需求應該在有限的資源(已知的能力、有限的系統(tǒng)及其環(huán)境)下是可實現(xiàn)的。為了避免需求的不可行性，在需求分析階段應該有核心技術人員參與，檢查在技術上什么能做、什么不

16、能做，哪些需要額外的付出等。(3)需求內(nèi)容應該是必要的。需求建議書中的每個需求都應該有相應的出處，即說明什么是客戶確實需要的，什么要順應于外部的需求、接口或標準。如果不能標識出處，則可能這個需求不是真正需要的。(4)需求內(nèi)容應該有優(yōu)先權(quán)。優(yōu)先權(quán)是由客戶或其代理及項目小組共同商討后建立的。如果所有的需求都被視為同等重要，那么在開發(fā)中遇到預t算削減、計劃超時或組員的離開而導致新的需求時，項目經(jīng)理將無所適從。一般優(yōu)先權(quán)有以下三個級別。1)高優(yōu)先權(quán)，表明需求必須體現(xiàn)在本階段項目的成果中或這個產(chǎn)品的版本中。2）中優(yōu)先權(quán)，表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中。3）低優(yōu)先權(quán)，表明有它很

17、好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。（5）需求內(nèi)容應該是明確的。需求不該有歧義，要避免使用一些對于擬訂項目需求建議書的人很清楚，但對于其他人模糊不清的詞匯。如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔、直觀地采用用戶熟知的語言，而不要采用計算機術語。需求建議書例子例：某企業(yè)項目管理軟件開發(fā)項目需求建議書有關單位：某企業(yè)（甲方）由于業(yè)務發(fā)展的需要，決定采用項目管理的方式進行管理，為了更有效地對項目的執(zhí)行過程進行控制，該企業(yè)決定開發(fā)一套項目管理軟件以滿足這一需要。13 工作表述開發(fā)商將執(zhí)行下面任務：開發(fā)項目管理軟件。開

18、發(fā)項目管理軟件的主要功能包括項目及工作信息的錄入、項目網(wǎng)絡計劃圖的繪制、項目時間計劃的安排、甘特圖計劃的制定、項目執(zhí)行信息的錄入與分析及各種計劃報表的輸出等功能。14 要求開發(fā)商應根據(jù)國家有關標準，提供開發(fā)計劃和實施方案。15 交付物符合甲方要求的項目管理軟件。16 甲方提供的條款甲方將幫助開發(fā)商熟悉項目管理流程。17 合同類型合同必須以一個商定的價格，給提供滿足需求建議書要求工作的開發(fā)商付18 到期日開發(fā)商必須在2004年11月30日以前提交5份申請書備份19 時間表甲方希望在2004年12月25日前選中一家開發(fā)商。這個項目需要完成的時限是2025周，從2005年1月1日開始實施項目，要求軟件正式驗收前試運行4周以上的時間，并根據(jù)試運行情況進行適當修改。20 付款方式當項目完成了1/3時付總額的1/3。當項目完成了2/3時再付總額的1/3。當甲方已經(jīng)滿意于項目100%的完成，并且開發(fā)商已經(jīng)履行了全部契約義務時再付出總額的1/3。21 申請書內(nèi)容(開發(fā)商的申請書至少包括如下內(nèi)容)(1)方法。開發(fā)商能清晰地理解需求建議書，理解什么是被期望達到的要求。而且要詳細描述開發(fā)商領導項目的方法，要求對每個任務的詳細描述，任務如何完成的詳細描述。(2)交付物。開發(fā)商要提供交付物的詳細描述。(3)進度計劃。列出甘特圖或網(wǎng)