谈技术建议书编写(1.8)

做售前有两个重要工作，一个是售前PPT讲解材料编写，一个就是应标的时候技术方案或者叫技术建议书的编写，今天先谈下应标过程中的技术建议书编写要点。

1. 通读标书了解项目范围和目标

当拿到标书的电子档材料候，首先应该通读整个标书，特别是里面的项目背景，目标，项目建设范围，详细的技术规范书说明，如果有详细打分表的还需要详细阅读技术打分表，了解项目技术打分的重点。

一般拿到标后，甲方都会安排一次标前答疑，对于应标团队要高度重视标前答疑工作，准备好相应的问题。其中问题重点还是应该是项目建设范围和实施范围，项目的关于技术约束，产品选型要求，同时也需要对标书中本身出现的前后不一致内容进行答疑。这些都是需要甲方进一步进行澄清的内容。当然如果应标团队有些关键技术不满足，或者觉得甲方设置不合理也可以标前答疑提出来，甲方认为建议合理也可以进行修正。

界定清楚项目范围是应标前最重要的事情，范围的不确定将导致后面建设和实施工作量出现成倍的差异。举例来说一个软件项目建设完成后，究竟是实施5个子公司还是30个子公司，这将带来工作量和项目费用的巨大变化。因此务必重视第一阶段的范围界定，不能有任何模糊的地方。

另外一个重要工作就是技术评分规则的详细分析，要明白你写的技术建议书更多要围绕技术评分规则展开，即技术评分项都能够在你的建议书中很明显的找到，方便专家评委进行阅读和打分。因此对于比较大的标，我们在制作标书的时候还会准备一个评标导引文件，告诉评委技术评分点内容在标书里面的哪个章节等。

2. 搭建技术建议书目录框架结构

在对投标项目的目标和范围都明确后，就可以开始搭建技术建议书的目录框架结构。注意有些技术标发出来本身就提供了技术建议书的目录结构要求，那么遵从甲方的要求就可以了，但是你还是可以在不破坏甲方目录结构的情况下在最后增加一个附录来编写你认为有必要说明的关键问题和公司技术亮点等。

如果技术标本身没有限定项目的目录结构，那么就需要我们自己搭建。那么首先我们来看对于软件类项目应标的时候技术建议书的一个通用大框架：

• 项目概述（包括项目背景，目标，项目建设范围等）
• 需求分析（重点是你对项目目标范围的理解，对关键建设内容逐个分析）
• 项目整体建设方案（总体架构，技术架构，功能架构-按建设范围逐层分解描述，部署方案，安全方案）
• 项目实施方案（实施方法论，团队组织，人员，进度计划等）
• 项目管理方案（标准项目管理方法论上修订）
• 项目案例说明（客户，项目规模，建设内容，实施周期，人员等）

下面我们以上内容的关键点做一个说明：

项目概述的内容基本从甲方提供的标书材料里面拷贝，不用去加工。重点是需求分析部分，需要分析部门说明你对项目建设目标内容的理解，你大概准备采用什么产品，技术来实现需求等。需求分析是衔接项目建设目标范围和项目整体解决方案间的桥梁。否则给甲方看文档的感觉就是两者之间脱节，不清楚你是根据目标如果就给出了一个整体方案和架构，而这些都需要在需求分析部分说明清楚。

最难的还是项目整体建设方案章节，你需要拿出一个总体架构图，这个架构图覆盖本期项目建设范围，同时体现完整的逻辑和分层。然后对这个总架构图进行分解，即成了后续各个子系统建设方案的详细描述。这个地方如何进行抽象整合，如何揉是最难的点。

同时整体方案也包括了部署架构，非功能性架构（安全，性能，管控，部署和网络）各方面的内容，这些都需要在整体解决方案中进行详细描述。所以不要简单的以为整体解决方案仅仅是功能架构的描述。如果安装企业架构的思路，那么整体解决方案应该分为：

总体架构描述（业务架构，应用架构，数据架构，集成架构，技术架构（非功能性架构全在这））,然后业务架构可以按流程线或业务域进行分解描述，应用架构按子系统分解展开详细描述。这样整体解决方案就形成了一个完整统一，紧凑的文档结构模式。

3. 建议书内容编写分工，架构设计

对于一个大项目的技术建议书编写，往往在搭建完整体目录结构后可以开始考虑进行内容分解，分解后安排到不同的人员去编写。比如不同的子系统方案安排到不同的人编写，对于标准和业务无关的技术方案安排到技术架构，对于IT基础设施和部署架构安排到工程人员编写。

对于这种大的技术建议书，统筹的人最重要，一个大的售前项目应标和技术建议书编写本身就是一个项目，需要有严格的项目计划和进度控制，啥时候完成哪部分的编写，啥时候整合，啥时候进行内容评审和修订，啥时候安排打印等都需要有明确的时间安排。否则很容易出现在交标前手忙脚乱的情况。

在内容编写的时候首先又要分出两部分内容：

• 哪些是原来建议书就写过的的标准化的内容，不用修改的?
• 哪些是需要根据本次应标项目有针对性的调整的?

也正是这个原因，如果经常做售前项目应标，不是简单的积累已有的技术方案和技术建议书，而是应该对产品功能说明，项目管理方法论，团队人员简历，运维和售后规范流程，项目案例等都准备独立的可复用的标准化，模块化文件。到了真正应标的时候，根据需要对这些内容进行组装和整合。

而实际我们要做的，对于整体解决方案里面就是整体架构设计，通过整体架构设计图和内容说明将前面的需求分析和后面的模块化产品说明串接起来形成一个整体。其次，就是实施方面，这个涉及到需要根据项目本期的业务目标和需求排项目的项目进度计划，安排项目人员等，这些也需要花较多时间准备。

4. 建议书内容整合和检查

最后一个阶段就是对建议书内容进行整合，整合完成后进行目录结构，字体，行距，错别字等基础的合规性检查。其次是按照项目目标范围要求，进行内容的检查，确认没有关键内容遗漏。最后就是基于项目技术打分表，进一步确认每个技术打分项都在提交的技术建议书里面有明确的描述，同时完成技术评分指引表，说明具体的内容位置。