PG官网

  一个区级政务平台招标，投标文件写了三百多页。技术方案里列了等保三级、信创适配、双活容灾、数据中台、AI 辅助审批，评分表上能加分的项几乎写满了。评审结果不错，公司顺利中标。项目做了八个月，验收会上，甲方信息中心主任翻到双活容灾那一节，问机房在哪。项目经理愣了几秒，合同里没有这一条，招标文件只写了机房托管，没写双活。

  这类事在政企项目里不算少见。投标阶段，技术方案是给评标专家看的，怎么完整怎么写，怎么显得有实力怎么来。中标之后，方案被装进档案袋，真正管项目的是合同、需求确认单和验收标准。两边对不上，验收会上就只剩一句话，你们投标时可不是这么说的。

一、加分项写得漂亮，合同里没人负责

  评分表决定谁中标，合同决定谁干活、干到什么程度。这两个东西长得像，法律效果差得远。评分表里的加分项，是评标委员会打分的依据，评委打完分，它的任务就结束了。合同里没写的承诺，中标后很难直接拿来要求乙方履约。甲方觉得你投标时答应了，乙方说那是技术方案里的描述，不是合同条款，扯来扯去，往往各让一步，项目留下一堆尾巴。

  政企项目常见的加分项，大概集中在几类。资质类有等保测评、CMMI、ISO 认证、信创名录、软件著作权。技术类有双活容灾、国产数据库适配、微服务架构、接口开放、数据中台。服务类有驻场人数、响应时限、培训场次、免费运维年限。这些词写在方案里很漂亮，落到合同里要变成可检查的东西，否则验收时没法判断做没做。

  拿双活容灾来说，方案里写两地三中心、RPO 接近零、RTO 不超过半小时，听着很专业。合同里如果只写系统要安全稳定，没有写机房数量、链路带宽、切换演练频次、演练报告由谁签字，验收时只能看乙方有没有买两台服务器。等保三级也一样，方案里写按三级要求建设，合同里没写测评机构、测评时间、整改责任，到头来可能只拿到一个备案证明。

  技术方案作为合同附件，是最常见的做法，但附件怎么写有讲究。有的合同只在附件目录里写一句技术方案见投标文件，然后把三百页方案钉在后面。这种写法看似完整，实际没人逐条核对。更稳的做法，是在合同正文后面加一张表，把每个加分项拆成承诺内容、交付物、验收方法、责任人、完成时间、违约处理。表和方案对得上，项目经理才知道自己要管什么。

  责任人不写清楚，加分项就会变成没人认领的活。商务经理觉得技术方案是技术部写的，技术负责人觉得合同是商务部签的，项目经理进场后只看到一份总价和工期。等到验收会，甲方问驻场为什么只有两个人，乙方说合同里没写人数。问培训为什么只有两场，乙方说方案里写的是建议。每个环节都能推，一层层推给项目经理。

  甲方那边也有自己的问题。评分表写得很细，合同里只写总价、工期和一句按国家规范验收。信息中心接手项目后，发现手里没有可执行的验收依据。想让乙方补做，乙方说合同没要求。想扣尾款，合同没写扣款条件。招标时省下的那点合同评审时间，验收时要花几倍补回来。

二、技术方案要对着评分表逐条落

  把评分表、投标响应和合同附件放在一张桌上，逐条对，是投标阶段最该做的事。左边写评分项和分值，中间写投标文件里的响应内容，右边写合同或验收条款。三列对不上，就说明这条加分项要么是废话，要么后面会扯皮。这个动作不复杂，难的是有人愿意在投标前去干。

  先分清两类东西。资质证书、案例合同、人员证书、软件著作权，这些是拿材料说话，投标时附扫描件，评标时核对原件。技术方案里的架构、性能、接口、培训、驻场，这些是拿交付说话，中标后要真的做出来。前一类造假会被废标，后一类吹牛当时没人管，验收时才暴露。

  评分办法里的分，也分客观分和主观分。客观分靠证书、案例、人员、报价，材料齐不齐一目了然。主观分靠评委对方案的理解，架构合不合理、思路清不清楚、风险有没有考虑到。主观分高的方案，往往写得漂亮，也更容易在验收时落空。投标时要把主观分的描述翻译成客观的交付物，不然评委给了高分，项目组接不住。

  评分表里最容易被写虚的，是支持两个字。要求支持国产数据库，响应就写完全支持，既不写哪几种数据库，也不写版本、迁移工具、数据量、性能指标。要求支持高并发，响应就写支持万级用户，不写测试环境、压测脚本、响应时间。评委看关键词给分，验收人员看实际结果，中间差着一整套可验证的指标。

  可验证的指标要尽量往数字上落。并发用户数、平均响应时间、可用性、数据迁移量、接口数量、驻场人天、培训课时、故障响应分钟数、恢复时间目标，这些都能写进验收表。不能量化的，也要写清楚判断方法，比如提供第三方测评报告，完成一次切换演练，提交甲方签字的培训签到表。写得越具体，后面越省事。

  技术方案不要只堆架构图。评标专家看一份三百页的方案，通常先翻目录，再找评分表里的关键词，剩下的内容未必细看。真正决定项目成败的，是那些关键词后面有没有交付路径。一个数据中台写五页，不如写清楚接哪几个业务系统、抽哪些数据、每天跑几次、异常怎么处理、谁来对账。

  投标团队和交付团队最好在投标前碰一次。写方案的人懂客户想要什么，做项目的人知道公司能不能做到。两边不碰，方案里就容易出现公司根本没做过的功能、没代理过的产品、没签过的人员。中标后交付团队翻开方案，第一反应是这活没法干，第二反应是找合同看有没有退路。

三、演示和 POC 要写进招标文件

  演示和 POC 是加分项里最容易走过场的环节。招标文件写一句安排现场演示，供应商就带着笔记本和录屏来，挑最顺的流程点几下，评委看完打个印象分。演示完没有记录，没有测试用例，也没有人签字，后面验收时想拿它当依据，基本拿不出来。

  要让它有用，招标文件里得写清楚几件事。演示环境是甲方提供还是乙方自带，数据是真实脱敏还是样例数据，演示时长多少，演示内容对应哪些评分项，评委由谁组成，演示过程要不要录像，演示结果要不要签字确认。这些看起来是细节，缺一项，供应商就能自己挑最简单的做法。

  POC 和演示不是一回事。演示看的是产品有没有这个功能，POC 看的是这个功能在甲方环境里能不能跑起来。POC 要用真实数据、真实接口、真实网络，至少要压一遍性能，跑一遍异常流程。只让供应商在自己电脑上打开一个页面，点两下就说通过了，那不叫 POC，叫产品介绍。

  POC 的准出条件也要先写。测哪些场景，每个场景的通过标准是什么，出现什么问题算不通过，不通过之后是整改、重测还是淘汰，测试报告由谁出，双方谁签字。没有这些，POC 结束以后，乙方说基本可用，甲方说问题很多，又是一轮扯皮。

  如果 POC 放在中标后做，最好写进合同，作为验收的前置条件。POC 不通过，甲方有权要求整改，整改仍不通过，可以按合同约定处理。如果 POC 放在投标前做，那它更像资格预审，得写进招标文件，让所有投标人按同一套场景和标准来，不能只让一家供应商试。

  演示和 POC 的证据要留。测试用例、操作日志、截图、性能报告、问题清单、整改记录、双方签字的结论，这些东西在验收会上比十页方案管用。口头说当时演示过，没人记得清，也没法追责。

四、验收标准前置，别等中标后再谈

  验收标准最晚要在招标文件里写，不能等中标后再谈。招标文件里的验收条款，决定了投标人怎么报价，也决定了甲方后面能不能顺利接手。只写一句按国家标准验收，等于把解释权交给双方的项目经理，谁强势谁说了算。

  验收资料也要提前列清单。需求确认单、测试报告、上线记录、数据迁移记录、操作手册、培训记录、按合同约定需要交付的源代码或部署包、第三方测评报告，这些东西谁提供、什么时候提供、格式是什么，合同里写清楚。验收会前两天才通知乙方准备材料，往往缺东少西，会议只能改期。

  验收条款可以分几层写。功能验收对需求清单，逐项确认有没有做完。性能验收对压测报告，写清并发量、响应时间、成功率。安全验收对等保测评和漏洞扫描，写清谁出报告、什么时候整改完。数据验收对迁移记录和比对结果，写清数据量、差异率、回滚方案。文档和培训也要验收，别等项目结束了才发现没有操作手册。

  验收流程也要写。初验做什么，试运行多久，终验要达到什么条件，缺陷分几级，每级修复时限是多少，逾期怎么处理，尾款什么时候付。政企项目常见的做法是初验后试运行三个月，试运行期间出现严重问题，时间重新算。这个规则要提前写，不能等出了问题再临时定。

  有些合同会写一句甲方未在期限内提出异议视为验收合格。这句话对乙方有利，对甲方风险很大。系统有没有问题，不是靠甲方有没有发函来判断。更稳的写法，是把验收条件、验收期限、整改期限、复验流程写清楚，双方按流程走，少用视为两个字。

  需求变更要和加分项分开。项目实施过程中，甲方加功能、改流程、换接口，属于变更，走变更单，评估工期和费用。不能因为投标时方案里提过一句，就当成免费赠送。乙方也要注意，变更太多会把原定的验收节奏打乱，到头来双方都觉得对方不讲理。

  投标时多写一条，可能多拿两分，也可能给项目埋一个坑。下次投标前，把评分表打印出来，和合同草案、验收模板摆在一张桌上，逐条对一遍。能落地的才写，落不了地的宁可不要那几分。