RFP在IT專案中是相當平凡的一個名詞也是相當重要的一份文件，它代表了導入方向賣方以文件方式提出需求，這個需求包含了專案所需的軟體、硬體、需求、預算、時程等說明，這份RFP通常也會伴隨合約成為合約的一部分。在ISO 20000(另一文章介紹) Part1第5節Service Delivery Processes-Service level management中也有提到The full range of services shall be agreed and documented. Each service to be delivered shall be recorded in an SLA(Service Level Agreements) together with the corresponding targets. 很明白的描繪出所有的服務需求必須被文件化，每一項服務的達到必須被記錄在服務文件中，與RFP所描述有異曲同工之妙，未來再專案的執行上有任何的爭端，都需要以RFP作為解釋的基礎 。
RFP的撰寫範例再網路上很容易都搜尋的到，每人寫法也會有所不同但是目標與方向均大同小異，我僅針對我接觸的專案介紹簡單的章節與範例。
壹、專案說明
一、簡介
二、專案名稱(例如自動化倉儲建置案)
三、專案目的(期望進出貨物管理達到自動化的效果)
四、專案目標(整合物流、人員控管落實資源共享之平台)
五、專案範圍(包含人事、財務、倉儲等系統)
六、專案時程(各項文件交付時間、硬體安裝時間、軟體開發期程、測試等工作項目之時程)
貳、現況說明(此章節可有可無，如果有舊系統或待整合之系統可簡述)
一、單位組織架構與職掌(簡述單位組織並描述工作職掌與其業務行為)
二、現行軟、硬體架構說明(如果已有運行中之系統，簡述其架構與功能)
三、現行系統使用量、瓶頸、效能之說明(可簡述舊平台之現況與新平台之期望)
參、專案需求說明
一、技術需求(簡述相容性、資訊安全、整合測試、系統備援等)
二、軟體需求(包含通用性、一致性、完整性等需符合通用語言、Y2K、民國百年序等標準)
三、硬體需求(包含資料庫、網頁伺服器硬體規格，建議效能說明、備援機制等也都要考量)
四、維運需求(需明白描述後續保固、維護相關說明)
PS.若軟、硬體由第三方協力商提供，需留意文字上保固與原廠保固之陷阱。
肆、專案管理說明
一、專案人員組成(描述專案經理、系統工程師、開發人員的素質與要求)
二、專案服務要求(描述人員調派、品質保證、工具使用、駐點服務及緊急應變之能力等)
三、專案管理需求(各類文件管理、定期專案會議、不定期緊急會議及時程追蹤等規畫)
四、服務異動管理(需說明雙方責任歸屬、人員及時程重新規劃等)
五、教育訓練執行(需包含技術與非技術面之教育訓練及明訂由原廠或承包商執行)
伍、產品交付與時程
一、交付內容清單(應說明軟硬體含開發工具之交付狀況、各類文件標準書寫規格及數量等)
二、交付時程(明訂交付時間，利如：各期交付或是全案驗收等)
陸、驗收及保固
一、驗收方式與原則(需明訂為分期驗收或全案驗收)
二、驗收清單(完整明列出RFP所要求項目是否有達到並完成交付，尤其是原始碼之權責釐清)
三、付款方式(需明訂為分期付款或全案驗收後付款，並訂定保證金規範)
四、保固及維護(需明訂保固起算日、叫修回覆時間、保固及維護範圍及由原廠或承包商執行)
柒、版權宣告
一、資料保護(本案所有相關文件、資料，未經正式同意不得轉載、複製、使用等需明文規範)
二、智慧財產權規範(本案所有自行開發或使用第三方之軟體，均需遵守智財權之規範)
三、本案標的物(本案所涉及之範圍，需由雙方訂定智財權之擁有者，使用權、修改權之規範)
四、保密切結(本案相關所有人員均需簽署保密切結，並訂定損害賠償之規範)
一個寫的好的RFP可以在專案進行期間減少雙方專案人員的爭議，在實際案例中依專案的大小一份RFP可能數十頁或是上百頁，其中內容規範可能依專案需求或是公司自己內部規範有所不同，本文簡述與經驗分享僅供參考，其他的就讓大家各自發揮了。
留言列表
