什么是需求建议书(RFP).pdf

需求建议书 （Request For Proposal, RFP） 什么是需求建议书 需求建议书 是指从客户角度出发， 全面、详细地向服务商陈述、 表达为了满 足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出 的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第 一份书面文件，又称招标书。需求建议书一般由客户起草， 主要描述客户的需求、 条件及对项目任务的具体要求。 一份完整的需求建议书主要包括满足其需求的项 目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契 约形式、项目时间、项目申请书的要求等。 好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非 在所有情况下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发 项目予以满足时， 这一过程似乎变得简单多了， 此时更多需要的是口头上的交流 和信息传递，而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书 上。例如，某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日 益增加的业务需要时， 便可直接要求软件开发小组进行开发，这时只需口头把相 关的要求传达给软件开发小组即可。 需求建议书的书写要求 书写 RFP要认真负责、严肃对待，内容要具体，语言要精练。 1在第一行正中写 “建议书 “ 三个字。 2写接受建议对方的名称。 3正文： （1）建议的原因或出发点，便于对方考虑。 （2）建议的具体事项。 4表达建议者的愿望。 5结尾写表示敬意的话，如“ 此致敬礼 “ 等语。 6写上建议者的名称和写建议书的日期。 需求建议书的结构和格式 1、标题 2、称谓 3、正文（开头部分，主体部分，结尾部分） 4、署名及时间 需求建议书的书写指导方针 需求建议书必须说明项目目标（project objective）或目的，包括任何可 能对承约商有用的合理信息或背景信息，以便承约商可以准备相应的建议书。对 外起草一份正式的需求建议书，有如下的指导方针： （1）需求建议书必须提供工作陈述（statement of work, SOW） （2）需求建议书中必须包含客户要求（customer requirements ）定义好规 格和属性。 （3）需求建议书中应当说明客户期望承约商或者项目团队提供什么样的交 付物。 （4）需求建议书中应当列明任何应由客户提供的物品。 （5）需求建议书中可能要说明需要客户审批的内容。 （6）某些需求建议书中会提到顾客想用的合同类型。 （7）需求建议书可能会表明顾客想用的付款方式。 （8）需求建议书应当表明项目完成所要求的进度计划。 （9）需求建议书应当指导并说明承约商申请书的格式和内容。 （10）需求建议书应当指出客户希望潜在承约商提交申请书的最后期限。 （11）需求建议书可能会包含评价标准。 需求建议书的主要内容 需求建议书一般包含以下主要内容： 客户必须搜集大量相关资料准备需求建议书，因为IT 项目实施者需要按照 RFP来准备他们的项目技术方案，并以此参与竞标。RFP中包括项目的目标，也 就是用户的期望， 也包括客户要求项目的进度计划；对实施商申请书的表格和内 容的规定；客户希望潜在的实施商提交投标申请书的最后期限；评价申请书的标 准等。一份好的 RFP应该包括以下一些内容。 1工作表述 工作表述就是说明项目的工作范围， 概括客户要求开发商或项目团队执行的 任务或工作单元， 说明项目所涉及的各种事情， 哪些必须由开发商或项目团队去 完成，哪些由客户自己去做。例如，一个办公自动化软件系统的具体目标。又如 建设一个网站，所需设备的采购任务， 是由客户自己完成， 还是由开发商去完成； 企业网站上的页面文字，是客户自己撰写，还是由开发商撰写等。 2任务要求 需求建议书必须要具体规定开发商需要完成任务的规格和特征，如要求涉及 大小、数量、颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的 物理参数和操作参数。例如，建立一个企业网站，可能要求在1 000人同时访问 的情况下不会产生堵塞的感觉， 网站的浏览页面不低于多少； 建立一个自动结账 和收款系统，可能要求每天能办理12 000 次交易的功能和其他特定的功能，如 在开出了发票的 30 天内没有收到账款，就会自动产生催款通知。具体的任务要 求，可能会成为将来的验收标准。 3交付物 交付物就是开发商所提供的实体内容，这在需求建议书中应该说明。例如， 对于自动结账和收款系统来说， 客户可能要求开发商提供硬件( 计算机 )、 软件(磁 盘和一些印刷品 )、操作手册和培训课程。交付物也可能包括客户要求开发商提 供定期进度报告或终期报告。 4客户供应条款 需求建议书还应该列出客户的供应条款。例如，客户需要建立一个网J 站， 可能需要向开发商提供企业内部的组织结构及各部门之间业务关系的详细说明， 包括信息流程的类型、信息流量和发生频率等。 5表述客户对需求的确认 需求建议书不是对客户需求的最后确认。最后的确认应该在对开发商提出的 方案进行评估之后。 例如印刷宣传手册， 可能在开印之前要经过客户审定；局域 网的建设， 在购买材料和设备之前， 客户必须审定开发商的技术方案。这一点在 需求建议书中必须向开发商说明。 6期望的合同类型 (1) 合同可以按固定价格订立。这样，开发商实际上就是费用包干。客户只 给固定的价钱， 不管开发商实际工作花费多少。 开发商必须保证功能的实现和质 量要求，超支的风险由开发商负担。 (2) 合同也可以规定开发商不承担风险，即在时间、原材料限制的条件下， 不论实际成本多少， 都会给开发商特定的报酬， 也就是所谓包工不包料。 在我国 现阶段的条件下， 由于质量检验和资信度水平不高，这种合同比较普遍。 在需求 建议书中，最好说明客户是希望采用那种类型的合同。 7期望的付款方式 付款方式可以分为一次性付款和分阶段付款；在开始前付款和结束后付款。 一般依项目的性质来定付款方式。如网页制作， 往往在项目末期付款； 而架设局 域网， 一般在方案确认后，付款 30以便开发商采购，工程结束验收后付满90， 留 10等到使用一段时间以后确认无问题时付清。具体付款方式需要合同双方 协商，但在需求建议书中，客户应该先提出自己的期望付款方式。 8要求的进度计划 进度计划的要求可能很粗， 如要求在 6 个月内完成； 也可以详细一些， 如多 长时间内完成方案设计和审定， 多长时间内完成硬件选购与安装，多长时间内完 成软件研制、 测试与安装， 最后开发商在系统安装调试后，在多长时间内提交所 有的系统文件和操作培训。 9申请书的格式和内容提示 为了便于在几个开发商之间进行比较和评价，申请书应该在形式上采取同一 个格式，内容的结构也应该一致。 这样对不同的申请者来说比较公平，也能减轻 客户在评审时的工作量。 客户在需求建议书中可以限定申请书的每一部分采用的 文字数量或页数。 10提交申请书的最后期限 申请书受理的截止日期是必须要交代清楚的。例如，要求开发商在接到需求 建议书后多少个工作口之内( 如 l 周之内、1 个月之内等 ) 提交申请书，或大家一 律在某月某日之前提交申请书。 这样做的目的是便于同时对众多的申请者进行比 较、评估，也是为了保持公正，不给某些开发商以额外的时间和机会。 11对申请书的评价标准 要告诉开发商客户将根据哪些准则来评价他提交的申请书。这样做的目的， 是指导开发商写好申请书。一般评价标准包括4 个方面的内容： (1) 开发商在类似项目中的经验。如他们近期是否在预算内按期完成了类似 的项目，客户对他们是否满意? (2) 开发商提出的技术方案是否合适。 如采用哪种类型的计算机软件?数据库 的设计、方法是什么 ?用来建立管理信息系统的是哪种语言?采用哪些供应商的设 备?等等。 (3) 进度计划。开发商是否能按照所要求的进度完成项目计划? (4) 成本。如开发商的报价是否合理?成本预算中有无漏算的条款?将来在执 行时有没有可能出现超支，或有无可能因过于节约而导致质量不能保证?有的申 请人为了争取合同，在报价上压低成本，到了执行阶段，或偷工减料，或增加成 本，结果导致所建系统的缺陷很多，或使最终成本大大超出原始的估算。对此需 要引起注意。 12资金总量 开发商总是希望了解客户有多少资金可以用于发展拟议中的真T 项目， 但客 户在需求建议书中，往往不愿意透露这个信息。其实，客户暗示大约的数字，告 诉开发商他打算花多少钱来办这件事是有好处的，这样可以使开发商能够提交与 资金水平相适应的申请书，提高在项目准备阶段的工作效率。 需求建议书的必要性 需求建议书 (RFP)是项目客户与开发商建立正式联系的第一份书面文件，也 叫招标书。 一般由项目的客户自己起草，主要描述客户的需求、 条件以及对项目 任务的具体要求，向可能的开发商发送。 需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建 议书而编制的需求规范。 虽然它不能确保客户据此就能获得理想的解决方案，但 却可以帮助客户发现那些尽可能接近自身需求的系统准备。其目的是从客户自身 的角度出发， 通过全面、 详细地陈述， 使开发商或项目团队理解客户所希望的是 什么，以可行的价格满足客户的已识别的需求。 对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议 书，这种情况下，客户的需求建议书就变得很重要。事实上，项目无论大小，都 需要编写需求建议书。 第一，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是 客户进一步明确自己的目标与需求的过程，并以此建立起客户与供应商进行深人 沟通的桥梁。 即使因为各种原因使得供应商看不到或不愿响应需求建议书，这种 努力也是值得付出的。 第二，需求建议书可节省选型的时间， 并使得对各供应商之间的比较变得更 容易。客户提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复 沟通，同时，有需求建议书作为基准， 客户可以约束各开发商以一致的格式提交 方案建议书，以提高各供应商之间的可比性。 第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时， 客户往 往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后， 有的 供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己 的方案建议书更具有吸引力， 甚至会提出一些需求建议书没有涉及的好想法来拓 展客户的思路。 编写需求建议书的一般原则 需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做 到。 所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的J 过程也 是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求 建议书没 有公式化的方法， 需要大量的实践经验。 以下是编写需求建议书需要把握的几个 原则： (1) 需求应该是正确的 。每个需求必须精确描述要交付的功能。确定需求内 容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需 求的正确 性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说： “ 这不是我们要的东西 ” ；“ 你没明白我们的意思 ” ，等等。 (2) 需求应该是可行的 。项目的需求应该在有限的资源(已知的能力、 有限的 系统及其环境 ) 下是可实现的。为了避免需求的不可行性，在需求分析阶段应该 有核心技术人员参与， 检查在技术上什么能做、 什么不能做， 哪些需要额外的付 出等。 (3) 需求内容应该是必要的 。需求建议书中的每个需求都应该有相应 的出 处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如 果不能标识出处，则可能这个需求不是真正需要的。 (4) 需求内容应该有优先权 。优先权是由客户或其代理及项目小组共同商讨 后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t 算削减、 计划超时或组员的离开而导致新的需求时，项目经理将无所适从。 一般优先权有 以下三个级别。 1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本 中。 2)中优先权，表明需求是必须的， 但是如果需要可以推迟到晚一些的产品版 本中。 3)低优先权，表明有它很好，但我们必须认识到如果没有充足的时间或资源， 它可以被放弃掉。 (5) 需求内容应该是明确的 。需求不该有歧义，要避免使用一些对于拟订项 目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容 易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需 要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。 需求建议书例子 例：某企业项目管理软件开发项目需求建议书 有关单位：某企业 ( 甲方) 由于业务发展的需要， 决定采用项目管理的方式进 行管理，为了更有效地对项目的执行过程进行控制，该企业决定开发一套项目管 理软件以满足这一需要。 1工作表述 开发商将执行下面任务：开发项目管理软件。 开发项目管理软件的主要功能包括项目及工作信息的录入、项目网络计划图 的绘制、项目时间计划的安排、 甘特图计划的制定、 项目执行信息的录入与分析 及各种计划报表的输出等功能。 2要求 开发商应根据国家有关标准，提供开发计划和实施方案。 3交付物 符合甲方要求的项目管理软件。 4甲方提供的条款 甲方将帮助开发商熟悉项目管理流程。 5合同类型 合同必须以一个商定的价格，给提供满足需求建议书要求工作的开发商付 款。 6到期日 开发商必须在 2004 年 11 月 30 日以前提交 5 份申请书备份。 7时间表 甲方希望在 2004 年 12 月 25 日前选中一家开发商。这个项目需要完成的时 限是 2025 周，从 2005 年 1 月 1 日开始实施项目， 要求软件正式验收前试运行 4 周以上的时间，并根据试运行情况进行适当修改。 8付款方式 当项目完成了 13 时付总额的 13。 当项目完成了 23 时再付总额的 13。 当甲方已经满意于项目100的完成， 并且开发商已经履行了全部契约义务 时再付出总额的 13。 9申请书内容 ( 开发商的申请书至少包括如下内容) (1) 方法。开发商能清晰地理解需求建议书，理解什么是被期望达到的要求。 而且要详细描述开发商领导项目的方法，要求对每个任务的详细描述， 任务如何 完成的详细描述。 (2) 交付物。开发商要提供交付物的详细描述。 (3) 进度计划。列出甘特图或网络图表，列出每月要执行的详细任务的时间 表，以便在要求的项目完成日期内能够完成项目。 (4) 经验。叙述一下开发商最近已经执行的项目，包括客户姓名、地址和电 话号码。 (5) 人事安排。列出将被指定为项目主要负责人的姓名和详细简历，以及他 们在类似项目中的成绩。 (6) 成本。必须说明总成本并提供一份项目的预算清单。 10 申请书评价标准 (1) 方案(30)。开发商提出建设方案。 (2) 经验(30)。被指定执行此项目的开发商和主要负责人的执行类似项目 的经验。 (3) 成本(30)。开发商申请书中所列的固定成本。 (4) 进度计划 (10) 。为了要在项目完成之日或在此日期之前完成项目，开 发商应提供详细的施工计划。