當更新電子商務網站或新增功能時，必需要準備的文件就是RFP（提案依賴書）。通過仔細考慮並用文書方式明確提出需求，可以避免糾紛，確保開發的順利進行。本文將會針對首次撰寫RFP的電子商務網站負責人，詳細解析RFP的意義、步驟、記載內容及撰寫重點。
RFP意味
RFP是Request for Proposal的簡寫，中文稱為「提案依賴書」。當需要對電子商務網站進行更新或替換時，會向系統公司提出系統構建需求，這時就需要以文件形式來展示實現的業務需求（問題的解決方法或理想完成的狀況），並請求對方提出方案。
RFI與RFP的區別
同樣要提交給系統公司的文件還有RFI。RFI是Request for Information的簡寫，指「資訊提供請求書」。雖然發包方同樣需要向開發方提出，但RFI的內容和RFP有所不同。RFI主要是要求開發方提供公司的資料、實績、技術或產品說明。
RFP則是發包方篩選最終承包對象時的具體提案資料，而RFI則是再進一步選定發包候補對象前的資料。
RFQ與RFP的區別
RFQ是Request For Quotation的簡寫，指「報價請求書」。RFP中雖已包含預算，但若需要提供詳細的報價，此時會製作RFQ。因此，RFP除了預算之外，還包括有其他需求和業務說明，與RFQ有明顯區別。
RFP的目的
RFP的目的在於準確傳達發包方的意圖、期望及問題，並消除發包方與系統公司的認知差異。
若不撰寫RFP僅以口頭傳達需求，或即使有書面資料但內容不清晰，不僅發包方的意圖不能完整表達給系統公司，可能還會導致不理想的提案。即使從多個業務者那裡取得報價，由於各業者的提案每每不同，選擇起來也會困難。這時RFP的存在就顯得尤為重要，使發包方的想法得以準確傳達，從而獲得適合的提案。
撰寫RFP的優點
撰寫RFP有以下幾個優點：
- 無法確實傳達發包方的需求目標變得明確
- 能夠在相同條件下比較多家系統公司
- 明確自家公司所面臨的問題並在內部共享
- 避免口說無憑的糾紛
透過撰寫RFP，可以細緻地列出所需資訊，準確傳達給對方。同時，也有助於在相同條件下比較不同系統公司的提案。
此外，撰寫RFP的過程須細緻了解自家的問題，使現狀得以重新整理。某些問題或許可透過改進工作流程解決，發現問題後積極提出也很好。
口頭交流可能引發糾紛，透過書面RFP來記錄明確資訊，可以避免此類情況發生。
撰寫RFP的步驟
撰寫RFP的步驟如下：
- 確認開發目的
- 了解現狀問題
- 提出解決方案
- 收集及選定系統公司資訊
- 撰寫及提交RFP
- 比較系統公司提案書及報價單
- 決定發包對象
1. 確認開發目的
若開發的目的不明確，則系統導入後，可能無法有效利用或出現使用認知差異，甚至引發問題。作為發包方需明確目的，並在內部達成共識。
2. 了解現狀問題
接下來，整理出自家目前所面臨的問題。透過訪問各部門以確認問題並達成認識一致。具體了解問題可更易總結系統需求及希望。
3. 提出解決方案
搞清楚問題後，接下來考慮問題解決的方法。系統是否解決問題應以達成目標為考量點。此外，也可以試試非系統解決方案。
4. 收集及選定系統公司資訊
篩選系統公司候選資料的過程，可利用RFI進行。
5. 撰寫及提交RFP
決定系統公司候選後，即開始撰寫具體RFP。撰寫具體項目前請精確描述希望的導入目的及要求。
6. 比較系統公司提案書及報價單
比較各系統公司提交的提案書及報價單。利用檢查表或評估表進行客觀比較。
7. 決定發包對象
對各公司進行評估後，選定最適合的公司。向相關部門報告結果，釐清與系統公司間的疑點後確定合約內容。
RFP的具體記載內容
那麼，RFP中應包含哪些內容呢？大體上分為如下幾項：
- 系統開發的全體概貌
- 公司概貌、目錄
- 項目概況
- 開發背景及目的
- 所面臨的問題
- 預計時間表
- 預算
- 具體提案需求
- 現有系統構成
- 現有系統問題及解決預期
- 必需需求
- 運維及保護
- 教育及培訓
- 其他需求
- 補充資訊
- 存在疑慮或不確定的事項
系統開發全體概貌
全體概況及目錄
首先，需要簡要概括RFP內容並提供目錄，便於讀者掌握全體內容後進一步閱讀。
項目概況
總結開發項目，以使系統公司能正確了解自身情況。主要包括以下幾個項目：
項目概要
簡述希望如何改進、開發系統的要點。
開發背景及目的
描述項目為何啟動、背景原因及目的。講述改進或開發所需的原因及其背景，將來希望達成的成果等，防止與系統公司之間的認知差異。
所面臨的問題
展示希望通過改進或開發解決的問題。描述現行系統現狀及困境外，如有可能也建議言及電子商務事業及營運組織的問題。
預計時間表
列出從篩選交易對象到項目結束的時間表。考慮內部資源及運營現狀，安排實際可行的流程。
預算
列出可分配給項目的大致預算，系統公司將根據範圍提供報價。然而，有情況下可不提供具體預算，以便系統公司提出更低報價。
具體的提案需求
記載新系統的具體需求，儘量詳細說明以獲取合適的提案。
現有系統構成
描述現行系統配置，明確對其他系統的影響範圍。利用圖表展示會更加清晰。
現有系統的問題及解決預期
展示現行系統的使用方式、存在問題及新系統對問題的解決預期。
必需需求
列出系統開發的必需需求，系統公司將根據這些需求提供具體提案。根據項目規模及開發內容，可包括以下需求項目：
系統開發的方法及規格
具體傳達與開發方法有關的具體需求（例如，ASP服務或包裹軟體等）。
有關功能的需求
列出具體需求以具象化理想狀態。
非功能性開發需求
與功能以外的系統需求有關，如UI（使用者界面）、擴展性、安全性等，具體表達。
運維及保護
提供服務後所需的維護與支持體系需求。
教育及培訓
提供新系統培訓需求，教導相關人員如何使用系統。
其他需求
表明以上未列項目，例如以下幾個內容可被包括：
- 納品成果物清單：如手冊或文件列表
- 團隊構成：系統公司團隊人員數目、構成及項目負責人姓名
- 工時：人月單位所需工時
- 進度安排
補充資訊
記載需要系統公司提供建議的技術需求或審議事項；此外，如競爭對手電子商務網站資訊等需讓對方瞭解的事項也應記載。
撰寫RFP的要點
為了讓RFP資訊更容易共享並便於理解，需注意以下幾點：
仔細了解現狀
若未正確把握現有電子商務網站的狀況及問題，即使提出理想目標，亦難以實現。因此需首先細緻審視現狀及問題，不僅包含相關部門，亦包括高層及內部不同部門的意見。
意識到讀者是外部人員
RFP是提交給外部人員的文件，需預設對方不瞭解自家業務，因此需儘量詳細描述。
具體記載數值
任務需求應儘量具體，以數值量化目標，減少模糊表達。描述改進電子商務網站後，訪問量或轉換率的提增預期數值，即使僅為估算亦可。
列出不確定及疑慮事項
在項目啟動階段，細節尚未決定是正常的。RFP中應列出當前未定、不確定或不瞭解的事項。將這些內容告知系統公司，對方或能基於此提供解決方案。
利用RFP與系統公司共享願景，促成項目成功
RFP（提案依賴書）是進行電子商務網站改進及替換時必不可少的文件。通過RFP，能清晰表達發包方的意圖及希望，並獲取最佳提案。提供具體的資訊及資料極為重要，以便與系統公司共享相同願景，促成改進或替換項目的成功。