在本文中，我們將分享關於如何構建 Request for Proposal（RFP）計劃的一些技巧， 列出編制RFP時要考慮的主要事項（其中許多經常被忽略），並提供典型 RFP 生命週期的指導。
與我們之前的文章一樣，我們必須留意成本，以便我們概述您在決定著手計劃 RFP 和下游流程成本時應考慮的一些財務問題。
鑑於現代IT基礎設施的複雜性，IT監控工具將是一個複雜的解決方案。為了充分確定網絡監測工具所需的要求，您需要聽取公司中不同部門的意見。正常情況下，這將包括IT運營人員、IT經理、服務交付經理，甚至法律，財務（採購）和資訊安全團隊等其他部門。IT解決方案及其提供的內容會影響每個人，所以不要低估構建 RF P的成本。通常需要多次更改才能完成，包括內部評論及不斷的日常變化。
避免這3種最常見的網絡監控失敗，您可以下載此免費電子書作參考！
建立您的RFP只是成本的一小部份，您必須知道參與整個RFP的供應商數量，並仔細考慮這一點，因為供應商數量越多，評估完成時的成本就越高。不要忘記，供應商通常會有不同問題需要您在最終提交日期之前回答，需要注意的是，愈多供應商便伯有愈多問題，令您處理查詢花費的時間更多，最終令團隊花費更多的成本和更少的時間來處理其他業務。
以下是一個典型RFP的結構， 我們不會深入研究各個部分的細節，但能讓你清楚明白包括不同項目的原因。
RFP 第1部分 - 介紹和目的
描述 RFP 的設計目標。例如：
- 我們公司希望在所有業務運營中選擇一個IT監控解決方案，我們有3個辦事處，都位於同一個國家，此網絡監控工具將需要監控全部辦事處的網絡和設備， 而我們的總部辦公室被指定為主要網路。
- RFP 將發給總共4個供應商。
RFP 第2部分 - 時間表
以下是 RFP 流程的預計時間。
- 第0週 - 向所有供應商發出 RFP 要求。
- 第0-2週 - 供應商可以提交關於 RFP 文件的任何查詢。
- 第4週結束 - 供應商必須在下午5點之前通過電子郵件提交 RFP 回覆。
- 第4-6週 - 公司將審查 RFP 回覆並尋求每個供應商的任何進一步了解。
- 第7週結束 - 公司將通知首選供應商為項目的主要供應商。
- 第8週 - 公司和首選供應商將在公司辦公室開會討論該項目，並確認雙方都希望進入下一階段。
- 第9週 - 公司將通過電子郵件通知其他參與供應商已經選出首選供應商，如無意外，將不會與其他供應商就 RFP 計劃下一步的會議。但公司很樂意與對未選定的供應商提供反饋意見。
RFP 第3部分 – 需求
本節將會佔 RFP 計劃的大部分， 包括供應商解決方案所需滿足的各種細節，並可能包括供應商公司本身的詳細資料，下面列出了一些典型例子 – 而在本例中，我們將以IT監控工具為主題。
1.供應商信息
- 供應商名稱
- 供應商辦公室地址
- 有關 RFP 的供應商聯繫人（包括姓名、電郵、電話號碼、地址等）
- 供應商公司狀態：私人持股或公開報價的公司？
- 現有供應商公司的數量
- 供應商附上最近3年經審核賬目的複印文件
2.功能要求（Functional Requirements）
這將圍繞IT解決方案需要提供的特性和功能的各種問題列表，通常由IT系統管理員和運營團隊編寫，必須留意所有的措辭是否簡潔地概括要點，從而讓投標者也能準確回應。
IT監控解決方案必須為IT管理人員和IT操作人員提供以瀏覽器為基礎的用戶界面。
3.非功能性要求（Non-Functional Requirements ）
這是一個經常被人遺忘的問題，許多公司也因此而大傷腦筋。以IT監控解決方案為例，則包括：
IT監控解決方案必須能夠每5分鐘探索出我們網路中所有250台設備，並在獲取網路數據的3秒內在管理系統控制台上顯示信息。
4.報告和分析要求（Reporting and Analytics Requirements）
這部分需要大量的思考，並為同時考慮到不同部門所需，因為報告和分析是大多數企業和股東的主要需求，這些企業和群體需要各種各樣的報告和數據視圖，建議在此先指定一些開箱即用的報告。同時詢問供應商是否包含自定義報告生成器，又可包括生成或自定義報告是否易用的問題。
5.安全要求（Security Requirements）
建議 RFP 中包括有關您的行業所需遵從的產品安全標準問題，並向供應商詢問他們使用其產品的安全流程和程序，以下是其中一些例子：
- 使用哪些工具和軟件編碼/測試技術來確保您的軟件產品符合行業安全的最高標準？請列出任何相關的安全標準（例如 ISO 27001 認證）。
- 您的產品是否遵守 OWASP Top 10 ？
6.操作要求（Operational Requirements）
本節內容非常廣泛，涉及支援、整合和相互操作性等，如以下問題：
- 供應商必須在周一至週五的上午9點至下午5點30分之間提供支持援服務。您好的支援服務時間是？請列出精確的時間，如午飯時間是否也包括在內。
- 供應商解決方案必須允許通過API與第三方系統整合。有提供哪些API機制？
- 我們將如何獲得修補程序或缺陷修復程序的通知？這些新版本將如何提供給我們？
7.部署要求（Deployment Requirements）
本節將重點討論在公司基礎架構中部署供應商產品的要求，要盡可能具體。
- 需要哪種數據庫以及哪個發行版本？
- 安裝供應商產品所需的硬件規格是什麼？
8.產品路線圖和版本（Product Roadmap and Releases）
本節通常會提供有關供應商有多經常發佈新產品，如以下問題：
- 主要和次要產品發佈的時間分別約多久？
- 產品版本的終結 (End of Life) 政策如何？
9.商業要求（Commercial Requirements）
本部分通常將由財務部門（採購團隊）準備，它通常會指定某些標準。如果供應商被選為首選投標人，則需要滿足這些標準。例如，
- 定價必須以某種貨幣報價
- 定價必須在 RFP 提交日期後的90天內有效
- 定價必須包含所有稅費
WhatsUp Gold 使網路監控變得簡單。
計劃 RFP 的提示和技巧
這裡有一些成功的建議，都是從以往建立 RFP 時汲取經驗的：
- 可以先指定 RFP 決策者，以保持流程達到預定時間表。
- 從不同部門選出合適人選，並建立 RFP 構建團隊。
- 建立 RFP 審查小組，可以包括 RFP 構建團隊的大部分成員。
- 確保 RFP 內容盡可能具體，以便供應商提交可量化而準確的信息，同時允許供應商適當的回應從而改進 RFP。
- 為您的 RFP 流程的每個階段設置可實現的時間表，如定義階段、內部審查階段、讓供應商回應的時間、RFP 評估階段和 RFP 結果階段通知等。
- 考慮你想用於你的 RFP 的格式，可以是 Word 類文件檔、Excel 等試算表類，也可以是混合格式，例如 Word 文檔中嵌入電子表格作更詳細解釋。
- 明確地說明什麼是供應商解決方案的強制要求，以滿足開箱即用，什麼是可選的（即他們可以通過額外的自定義腳本來滿足），以及什麼是「最好可以符合」
- 關於要求部分，建議您設計一個簡單的評分機制，以協助您在 RFP 評估階段做出決策，例如，3分為完全滿足要求，1分為滿足部分要求和0分代表不能滿足。
- 最後，根據筆者的經驗，以 “驗收測試”的形式來撰寫要求部分是一個好主意。正如我們在一開始所說的那樣，將您的跨職能團隊聚集在一起構建您的 RFP 需要花費巨大的成本。請謹記，RFP 只是一個讓您選擇首選供應商的指南。之後階段則十分重要，便是評估並驗證首選供應商產品實際在您的工作環境中是否真的能滿足您的要求。您需要建立一個跨部門團隊來“ 測試”供應商的產品是否能滿足所有需求，所以通過定義驗收測試等要求，您將可簡化整個流程的下一個階段，從而為您節省時間和人力成本。