# 技术选型与PoC执行手册

## 手册概览

| 项目 | 说明 |
|------|------|
| **适用场景** | 交通管理机构/企业需要选择关键技术方案或平台（如智能交通管理平台平台、AI信控系统、数字孪生平台、信号机、RSU等），通过结构化选型和PoC验证确保选对 |
| **核心工具** | 交通科技选型七维决策矩阵（功能匹配度/技术架构/国产化合规度/关基保护/供应商能力/性价比/实施风险）+ PoC五步验证法 |
| **总周期** | 12-16周（含4-6周PoC） |
| **交付成果** | 需求规格书、RFP/RFI文档、供应商长名单/短名单、PoC评估报告、供应商推荐报告 |
| **评估团队** | 技术架构师1人 + 业务分析师1人 + 采购/商务1人 + PM 1人 + PoC测试工程师1-2人 |

---

## 第一阶段：需求定义（第1-2周）

### 1.1 功能需求模板

**使用以下模板逐项定义功能需求。每个需求标注M（Must/必须有）/S（Should/应该有）/C（Could/可以有）/W（Won't/本期不做）。**

| 需求编号 | 需求名称 | 需求描述 | 优先级MoSCoW | 验收标准 | 关联业务场景 |
|----------|----------|----------|------|----------|------|
| FR-001 | 实时交通流数据接入 | 系统应支持接入线圈、雷达、视频、GPS浮动车等多源交通流数据，延迟不超过500ms | M | 至少接入4种数据源，端到端延迟<500ms | 交通态势感知 |
| FR-002 | 交通事件自动检测 | 系统应支持基于视频AI的交通事故、拥堵、逆行、行人闯入、抛洒物等事件自动检测 | M | 检测准确率>90%，误报率<15% | AI视频事件检测 |
| FR-003 | 信号配时方案自动推荐 | 系统应基于实时流量数据，自动生成并推荐信号配时方案，供交通工程师确认后下发 | S | 方案生成时间<30秒，工程师可一键下发 | AI信号控制 |
| FR-004 | 开放数据API | 系统应提供RESTful API接口，支持第三方系统获取脱敏后的交通数据 | S | API响应时间<200ms，含认证和限流 | 数据开放与共享 |
| FR-005 | 数字孪生3D可视化 | 系统应提供基于WebGL的交通三维数字孪生可视化，支持>1000个路口同时渲染 | C | 帧率>30fps@1000路口 | 数字孪生展示 |
| ... | ... | ... | ... | ... | ... |

### 1.2 非功能需求模板

| 需求编号 | 类别 | 需求描述 | 量化指标 | 优先级 |
|----------|------|----------|----------|--------|
| NFR-001 | 性能 | 系统并发处理能力 | 支持>5000路视频并发接入，>1000个路口实时计算 | M |
| NFR-002 | 可用性 | 系统可用率 | 核心功能SLA >99.9%（全年停机<8.76小时） | M |
| NFR-003 | 可扩展性 | 水平扩展能力 | 支持从100路口扩展到10000路口，无需架构重构 | M |
| NFR-004 | 安全 | 等保测评 | 满足等保2.0第三级(S3A3G3)要求 | M |
| NFR-005 | 国产化合规 | 本地化化适配 | 支持本地化CPU(ARM/x86)、本地化OS(统信/麒麟)、本地化数据库(达梦/人大金仓) | M |
| NFR-006 | 数据安全 | 数据分类分级 | 支持核心/重要/一般三级数据分类，自动脱敏引擎 | M |
| NFR-007 | 可维护性 | 运维友好度 | 提供统一运维监控平台、日志中心、自动告警 | S |
| NFR-008 | 兼容性 | 存量系统对接 | 支持对接主流信控系统（海信/莱斯/博康/西门子） | M |
| NFR-009 | 容灾 | 灾备能力 | RPO<15min, RTO<2h，支持主备/双活部署 | S |
| NFR-010 | 国际化 | 多语言支持 | 暂不要求 | W |

### 1.3 RFP/RFI结构模板

**RFI（信息邀请书）结构——用于长名单阶段：**

1. **项目背景**（0.5页）：单位简介、本次RFI的目的
2. **需求概述**（1-2页）：主要功能和非功能需求摘要
3. **供应商信息要求**（30个问题，见2.2）
4. **回复格式要求**（0.5页）：格式、截止日期、提交方式
5. **评估流程说明**（0.5页）：后续流程（RFI→短名单→RFP→PoC→终选）
6. **免责声明**：RFI不构成技术采购承诺

**RFP（方案建议书）结构——用于短名单阶段：**

1. **技术方案须知**（2页）：项目概述、时间表、技术方案规则、方案评审标准公开
2. **技术需求规格书**（10-15页）：从1.1和1.2生成
3. **商务要求**（2页）：报价模板、付款条件、质保要求、培训要求
4. **合同条款草案**（3-5页）：SLA、知识产权、保密、违约责任
5. **评分标准**（1页）：技术分70%+商务分30%（包含各子项权重）

### 1.4 权重设定工作坊

**参与人：** 业务方+技术方+采购方，各2-3人

**方法：** 层次分析法（AHP）简化版——两两比较矩阵

**步骤：**
1. 列出7个评分维度（功能/技术/国产化/关基/供应商/性价比/风险）
2. 每人填写两两比较矩阵（"A比B重要多少"：1-9分，1=同等，9=A远重要于B）
3. 汇总各人矩阵→计算几何平均→一致性检验（CR<0.1为通过）
4. 归一化得到各维度权重

**示例权重结果（典型智能交通管理平台项目）：**

| 维度 | 权重 | 说明 |
|------|------|------|
| 功能匹配度 | 25% | 满足业务需求是第一位的 |
| 技术架构先进性 | 15% | 需支撑未来5年发展 |
| 国产化合规度 | 15% | 大型项目刚性要求，权重逐年提高 |
| 关基保护能力 | 10% | 关基单位必考，非关基单位可选 |
| 供应商能力 | 15% | 实施和运维能力与产品质量同等重要 |
| 性价比 | 15% | 大型项目虽不唯低价，但预算纪律严 |
| 实施风险 | 5% | 作为扣分项而非加分项 |

---

## 第二阶段：市场扫描与长名单（第3-4周）

### 2.1 供应商研究来源

| 来源 | 适合信息 | 获取方式 | 可靠度 |
|------|----------|----------|--------|
| 采购网公告 | 历史选定记录、选定价格、竞争对手 | 公开查询（中国采购网、省市采购网） | ★★★★★ |
| 行业研究报告 | 市场份额、技术趋势、竞争格局 | 购买/订阅（赛文交通网、ITS114等） | ★★★★ |
| Gartner/IDC/Forrester | 全球技术评级、魔力象限 | 购买/订阅 | ★★★★ |
| 行业展会/论坛 | 最新产品、技术路线 | 参加（ITS世界大会、交通展等） | ★★★★ |
| 供应商官网 | 产品介绍、案例、白皮书 | 公开浏览 | ★★★ |
| 同行推荐/口碑 | 真实使用体验、隐性问题 | 非正式渠道（微信群/饭局/同行交流） | ★★★★（但需交叉验证） |
| 试用/PoC | 产品真实表现 | 与供应商合作开展 | ★★★★★ |
| 社交媒体/技术博客 | 开发者生态、技术活跃度 | GitHub/技术论坛/知乎 | ★★★ |

### 2.2 RFI 30个问题模板

**向每个候选供应商发送标准RFI问卷，以下是30个核心问题：**

**公司基本信息（Q1-5）：**
1. 公司全称、注册地、注册资本、成立时间、股权结构
2. 在交通行业的从业年限、累计交付项目数量、Top 3 同类项目案例（含客户方、金额、年份）
3. 公司总人数、研发人员占比、交通行业技术团队规模
4. 是否有ISO 9001/CMMI/ISO 27001/ITSS等资质认证？
5. 近3年有无重大诉讼、行政处罚或项目重大延期记录？

**产品与技术（Q6-15）：**
6. 请提供产品的技术架构图（包括计算层、存储层、中间件层、应用层）
7. 系统的开发语言和技术栈是什么？数据库选型？
8. 是否支持本地化化部署？（请逐一标注：CPU/OS/数据库/中间件的本地化适配状态）
9. 系统的API开放程度？是否提供完整的API文档和SDK？
10. 系统的最大并发能力？单个路口的计算延迟？
11. 系统采用什么方式处理数据安全，是否通过等保2.0测评（S3A3G3）？
12. 是否支持多租户/多级部署架构？
13. 是否有AI/ML能力？具体采用什么算法框架？是否自研？
14. 系统版本迭代周期是多久？最近一年的功能更新有哪些？
15. 技术路线的未来3年规划是什么？

**实施与交付（Q16-22）：**
16. 一个典型同类项目从签约到上线需要多长时间？
17. 实施团队怎么配置？项目经理的经验要求？
18. 是否支持定制开发？定制开发占项目的比例一般多大？
19. 系统上线后，运维服务怎么提供？（驻场/远程/响应时间/SLA）
20. 是否有培训体系？培训课程和资料有哪些？
21. 如果项目中途更换供应商，知识转移和数据迁移怎么处理？
22. 过去3年项目上线的按时交付率和客户满意度？

**商务与合作（Q23-30）：**
23. 产品定价模式？（许可/订阅/按量/定制）是否有公开的报价体系？
24. 典型的3年TCO（包括许可+实施+运维+升级）大约在什么范围？
25. 是否愿意接受PoC验证？PoC的开展方式和条件？
26. 知识产权怎么约定？定制开发部分的源码是否交付？
27. 维保到期后的续费行业规范？是否有锁定风险？
28. 国家强制性标准/GAT标准/行业标准/团体标准的参与制定情况？
29. 对于关基保护有什么专项能力或认证？
30. 请提供3个可以联系参考的客户案例（含联系人、职位、联系方式）

### 2.3 长名单入围标准

**最小入围门槛（必须满足所有Must条件）：**

| 条件 | Must标准 |
|------|----------|
| 行业经验 | 至少3个同类交通项目交付案例 |
| 技术架构 | 架构描述清晰、无明显过时技术栈 |
| 国产化合规 | 至少支持部分本地化化（CPU或OS或数据库，三者至少一项） |
| 公司规模 | 研发团队>30人或交通行业营收>2000万/年 |
| 服务能力 | 在项目所在地有分公司/办事处/合作伙伴（或承诺设立） |
| 法律风险 | 无重大诉讼和行政处罚 |
| PoC意愿 | 原则上愿意参与PoC（PoC条款可后续谈） |

**长名单筛选结果：**
> 通常从30-50家供应商中选出10-15家进入长名单

---

## 第三阶段：短名单与方案评估（第5-6周）

### 3.1 方案评分表

**从长名单中选出3-5家进入短名单：基于RFI回复和方案建议书评分。**

| 评分维度 | 权重 | 供应商A | 供应商B | 供应商C | 供应商D | 供应商E |
|----------|------|---------|---------|---------|---------|---------|
| 功能匹配度（有5分制评分子维度） | 25% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 技术架构 | 15% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 国产化合规度 | 15% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 关基保护 | 10% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 供应商能力 | 15% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 性价比 | 15% | 评分 | 评分 | 评分 | 评分 | 评分 |
| 实施风险 | 5% | 评分 | 评分 | 评分 | 评分 | 评分 |
| **加权总分** | **100%** | **X.XX** | **X.XX** | **X.XX** | **X.XX** | **X.XX** |
| **排名** | | | | | | |
| **是否入围短名单** | | ✅/❌ | ✅/❌ | ✅/❌ | ✅/❌ | ✅/❌ |

### 3.2 供应商演示评估表

**供应商演示日（Demo Day）评分表：**

| 评估项 | 权重 | 评分(1-5) | 评价要点 |
|--------|------|------|------|
| 演示准备充分度 | 5% | | 是否按照要求场景演示？演示环境是否就绪？是否有技术故障？ |
| 核心功能演示 | 30% | | 覆盖了多少必选需求(FR-Must)？功能是否真实可用（非PPT演示）？ |
| 技术能力呈现 | 20% | | 展示的技术架构是否清晰？对技术问题的回答是否专业？ |
| 业务理解深度 | 15% | | 是否展现了交通行业的理解？能否用业务语言而不仅是技术语言表达？ |
| 用户体验 | 10% | | 操作流程是否流畅？界面是否友好？上手难度如何？ |
| 团队素质 | 10% | | 项目经理和架构师的专业素质、沟通能力、应变能力 |
| 开放性与生态 | 5% | | API开放程度、ISV生态、社区活跃度 |
| 价格透度 | 5% | | 报价是否清晰透明？有无隐藏费用？ |

**Demo Day组织指南：**
- 每个供应商分配2小时（含15分钟环境准备+90分钟演示+15分钟Q&A）
- 提前2周发送演示场景清单（选择Top 5核心业务场景要求演示）
- 禁止使用PPT+录屏——必须Live演示真实系统
- 所有评估人员在演示结束后独立打分，不现场讨论
- 如果有条件，录制演示过程供后续回顾

### 3.3 客户参考访谈脚本

**对被推荐的参考客户进行电话/视频访谈，访谈提纲如下：**

| # | 问题 | 关注点 |
|---|------|--------|
| 1 | 您在什么时间购买了XX供应商的什么产品？ | 确认项目真实存在 |
| 2 | 项目的规模多大？覆盖了什么范围？ | 与自身需求的规模可比性 |
| 3 | 从项目启动到正式上线用了多长时间？是否延期？ | 项目交付能力 |
| 4 | 系统上线后，核心功能是否达到了预期？ | 产品真实表现 |
| 5 | 系统稳定性怎么样？有没有出现过重大故障？ | 产品质量 |
| 6 | 供应商的技术支持和售后服务满意度如何？ | 服务能力 |
| 7 | 和供应商合作中遇到的最大挑战是什么？ | 隐性问题挖掘 |
| 8 | 如果重新选择，还会选这家吗？为什么？ | 综合满意度 |
| 9 | 有没有什么你希望提前知道、但当时没了解到的事？ | "坑"的挖掘 |
| 10 | 还有什么想给我们的建议？ | 开放收尾 |

**参考访谈注意事项：**
- 至少访谈2家客户，每家至少2人（IT负责人+业务负责人）
- 供应商可能只推荐"友好客户"——主动通过行业圈子寻找非推荐客户进行交叉验证
- 如果供应商无法提供3个可联系的参考客户→红牌，降低信任度
- 参考访谈报告作为评审文件的一部分归档

---

## 第四阶段：PoC设计与执行（第7-12周）

### 4.1 PoC范围模板

**PoC范围书（1页A4）：**

```
PoC名称：[XX智能交通管理平台平台——区域自适应信控场景PoC]
PoC目标：验证XX平台在真实交通环境下（XX市XX区10个路口）的自适应信控能力是否满足要求

参与供应商：
- 供应商A（入围短名单第1）
- 供应商B（入围短名单第2）
- 供应商C（入围短名单第3，候选）

PoC周期：6周（2026.8.1 - 2026.9.12）

测试场景（4个核心场景）：
1. 单点路口自适应信号控制
2. 3个路口组成的短干道绿波协调
3. 高峰时段饱和流量自适应控制
4. 特殊事件（事故/施工）下的信号应急方案

测试数据：
- 10个路口的实时视频流（每路口2-4路）
- 线圈/雷达流量数据（历史6个月+实时）
- 信号机状态数据
- 天气数据

测试环境：
- 供应商自备服务器/云资源（不接入生产系统）
- 通过镜像/旁路方式获取数据（不影响现网运行）

关键成功指标：
| 指标 | 目标值 | 测量方式 |
|------|--------|----------|
| 通行延误降低率 | >10% | PoC前后浮动车对比 |
| 平均停车次数减少 | >15% | 视频AI统计 |
| 系统计算延迟 | <200ms | 从数据进入到方案输出计时 |
| 系统可用率 | >99%（PoC期间） | 监控系统自动记录 |
| 交通工程师满意度 | >4.0/5.0 | 每周问卷 |

PoC工作安排：
- 第1周：环境部署、数据对接、基础功能验证
- 第2-3周：场景1-2测试
- 第4-5周：场景3-4测试
- 第6周：效果评估、报告撰写

PoC预算：XX万元（含差旅、设备租赁、交通管制配合等）
```

### 4.2 测试场景设计模板

**每个测试场景使用以下模板描述：**

| 字段 | 内容 |
|------|------|
| 场景编号 | TC-01 |
| 场景名称 | 单点路口自适应信号控制 |
| 业务背景 | 路口X位于主干道与次干道交汇处，早晚高峰潮汐现象明显，周末流量模式不同 |
| 测试步骤 | 1. 系统接入路口实时流量数据（线圈+视频）→ 2. 系统根据实时流量自动生成配时方案→ 3. 交通工程师审核方案→ 4. 信号机执行新方案→ 5. 连续运行7天采集效果数据 |
| 输入数据 | 线圈流量（1min粒度）、视频流（每方向1路）、信号灯状态、时间/日期 |
| 期望行为 | 系统每15分钟评估一次配时效果，当流量变化>20%时自动推荐新方案 |
| 成功标准 | 通行延误降低>10%；高峰方向绿灯时间自动延长，低峰方向自动缩短 |
| 失败标准 | 延误不降反升；信号方案频繁切换导致驾驶困惑（>3次/小时） |
| 数据采集要求 | 浮动车数据（PoC前1周基线 vs PoC期间）、信号配时日志、交通工程师评价 |

### 4.3 PoC评估记分卡

**对每个参与PoC的供应商，按以下记分卡独立评分：**

| 评估维度 | 子项 | 权重 | 供应商A | 供应商B | 供应商C |
|----------|------|------|---------|---------|---------|
| **功能实现度（35%）** | 场景1通过率 | 10% | X% | X% | X% |
| | 场景2通过率 | 10% | X% | X% | X% |
| | 场景3通过率 | 10% | X% | X% | X% |
| | 场景4通过率 | 5% | X% | X% | X% |
| **性能表现（25%）** | 计算延迟 | 10% | Xms | Xms | Xms |
| | 系统可用率 | 10% | X% | X% | X% |
| | 并发处理能力 | 5% | X路 | X路 | X路 |
| **易用性与体验（15%）** | 操作流程流畅度 | 5% | 评分 | 评分 | 评分 |
| | 告警/通告合理性 | 5% | 评分 | 评分 | 评分 |
| | 文档/帮助质量 | 5% | 评分 | 评分 | 评分 |
| **集成与开放（15%）** | API易用性 | 5% | 评分 | 评分 | 评分 |
| | 数据导入导出 | 5% | 评分 | 评分 | 评分 |
| | 第三方系统对接能力 | 5% | 评分 | 评分 | 评分 |
| **团队合作（10%）** | 响应速度 | 4% | 评分 | 评分 | 评分 |
| | 问题解决能力 | 3% | 评分 | 评分 | 评分 |
| | 主动性和专业性 | 3% | 评分 | 评分 | 评分 |
| **加权总分** | | **100%** | **X.XX** | **X.XX** | **X.XX** |
| **排名** | | | | | |

### 4.4 PoC后勤检查清单

**硬件/环境检查：**
- [ ] 每个供应商的服务器/云资源已按时到位
- [ ] 网络带宽满足要求（测试视频流+数据量）
- [ ] 与生产系统的数据对接接口已开通并测试通过
- [ ] 测试路口已完成交通影响评估和备案
- [ ] 测试环境的访问权限已分配（VPN/堡垒机/跳板机）

**人员检查：**
- [ ] 每个供应商的驻场工程师已到位
- [ ] 客户方全程参与人员已确认（交通工程师/IT运维）
- [ ] 第三方数据采集机构（如有）已签约
- [ ] 交通管制/施工配合（如需）已向交管部门报备

**流程检查：**
- [ ] PoC启动会已召开，各方已签字确认PoC范围和时间表
- [ ] 每日站会运行框架已建立（推荐15分钟/天，人+内容+问题+计划）
- [ ] 每周进度评估运行框架已建立（与关键干系人同步）
- [ ] 数据采集工具（浮动车/问卷/监控系统）已就绪
- [ ] 应急回滚方案已确认（如果PoC影响现网时怎么办）

**法律/商务检查：**
- [ ] 保密协议已签署
- [ ] PoC期间的投入/费用承担已书面明确（哪方承担什么成本）
- [ ] PoC数据的所有权已明确（属于客户方）
- [ ] PoC失败不构成任何采购承诺（书面确认）

### 4.5 常见PoC陷阱及避免方法

| # | 陷阱 | 表现 | 避免方法 |
|---|------|------|----------|
| 1 | PoC范围蔓延 | 供应商主动展示额外功能，客户要求"顺便也测测那个" | PoC范围书必须双方签字，任何新增需求走正式变更流程 |
| 2 | 供应商使出"特种部队" | 总部研发总监亲自坐镇，代码24小时改——但交付团队不是这个水平 | 要求供应商用交付团队做PoC（不是售前团队，更不是研发总部），并在方案文件中承诺交付团队配置 |
| 3 | 哑铃效应 | PoC中功能A和功能B都展示过，但从来没人同时演示A→B的联动 | 场景设计必须覆盖端到端全流程，不能只测孤立功能 |
| 4 | 数据作弊 | 供应商用预训练的模型、缓存好的结果或理想化数据 | 要求使用客户的真实数据（可脱敏），进行实时计算（非离线批处理），数据量要够 |
| 5 | 只测正常路径 | 只测试了"一切正常"下的表现，没有测试异常/边界/压力 | 至少30%的测试用例覆盖异常场景（数据延迟/缺失/异常值/并发冲击/断电恢复） |
| 6 | 从众效应 | 看到供应商A的PoC结果很好，下意识给供应商B和C也高分 | 每个供应商独立评分，不共享评分结果直到全部PoC完成 |
| 7 | 没钱做PoC | 预算中没有PoC经费，执行时处处受制 | 在RFP预算中预留PoC经费（建议总预算的2-5%） |
| 8 | PoC=免费提前交付 | 供应商把PoC做成了实际交付，PoC结束后"挟系统以令客户" | PoC环境与生产环境物理隔离，PoC结束后供应商必须清除所有数据和代码 |

---

## 第五阶段：终选与谈判（第13-16周）

### 5.1 推荐报告模板

**供应商推荐报告标准结构：**

1. **执行摘要（1页）**
   - 推荐供应商及排名
   - 选型决策的关键理由（2-3条）

2. **选型过程回顾（1页）**
   - 时间线（RFI→短名单→RFP→Demo Day→PoC→终选）
   - 参与人员、评估方法

3. **各供应商评估详情（每供应商3-4页）**
   - 功能匹配度分析
   - PoC表现总结
   - 技术架构评价
   - 国产化合规评估
   - 商务条件分析
   - 优势与风险

4. **综合对比矩阵（2页）**
   - 七维雷达图叠加
   - 分阶段TCO对比表
   - SWOT分析

5. **推荐建议（1页）**
   - 第一推荐、第二推荐、不推荐名单及理由
   - 建议的谈判策略和关键条款

6. **附录**
   - PoC详细评分数据
   - 参考客户访谈记录
   - RFI回复汇总

### 5.2 谈判策略

**谈判准备七步法：**

| 步骤 | 内容 | 输出 |
|------|------|------|
| 1. BATNA分析 | 如果和首选供应商谈不成，次选是谁？次选比首选差多少？ | BATNA卡片 |
| 2. 谈判区间分析 | 研究供应商"可能接受的最低价格"和"最初报价"之间的区间 | 谈判区间估计 |
| 3. 条款优先级 | 列出必守条款（如源码交付、国产化认证）和可让条款（如付款节奏） | 条款优先级矩阵 |
| 4. 价格拆解 | 把总价拆成许可/实施/培训/运维/升级，逐项比照行业benchmark | 价格拆解表 |
| 5. 竞争博弈 | 适当让供应商知道存在强力竞争者（但不能透露具体评分），制造FOMO | 竞争态势沟通策略 |
| 6. 捆绑与分拆 | 考察是否值得捆绑后续项目（价格更优）还是分拆（降低依赖性） | 捆绑/分拆策略 |
| 7. 谈判剧本 | 设计谈判节奏：先谈什么后谈什么，谁先出价，什么时候亮BATNA | 谈判剧本 |

**关键谈判条款清单：**

| 条款 | 建议立场 | 谈判弹性 |
|------|----------|----------|
| 知识产权（定制开发部分） | 要求源码交付+客户方拥有所有权 | 最低接受：客户方拥有不可撤销的永久使用权 |
| 产品许可模式 | 尽量争取买断制（CapEx），而非订阅制（OpEx） | 如必须订阅，锁定3-5年价格+涨价上限 |
| 维保费年涨幅 | 首年包含在项目款中，后续维保不超过合同额15%/年 | 可接受10-15%，但要求价格保护至第5年 |
| 源码托管 | 要求供应商核心源码第三方托管（Escrow），防止供应商破产/被收购后系统无法维护 | 客户方强需求，不建议让步 |
| SLA与惩罚 | 可用率99.9%+，超出停机时间的赔偿（建议：每超1小时赔合同额0.1%） | SLA可微调，但惩罚运行框架必须存在 |
| 锁定条款 | 禁止"只能用该供应商的配套硬件/升级服务"的隐性锁定 | 不可让步 |
| 付款节奏 | 建议3:3:3:1（签约/初步验证/最终验证/质保到期），降低预付款比例 | 可协商，但尾款不少于10% |
| 人员锁定 | 关键人员（项目经理/架构师）更换须客户方书面同意 | 不可让步 |

### 5.3 合同审查检查清单

**签约前24项审查清单：**

**商务条款（8项）：**
- [ ] 合同总价与谈判结果一致，无隐含收费项
- [ ] 付款条件和节奏与谈判结果一致
- [ ] 质保期和维保条款清晰，包含SLA和服务目录
- [ ] 知识产权条款明确——核心关注：定制开发部分的源码归属
- [ ] 违约责任条款清晰且对等
- [ ] 保密条款覆盖双方
- [ ] 争议解决方式（仲裁/诉讼）和管辖地明确
- [ ] 不可抗力条款合理

**技术条款（10项）：**
- [ ] 需求规格书作为合同附件，标注版本号和日期
- [ ] 验收标准和验收流程明确（初步验证/最终验证/质保到期验收）
- [ ] 交付成果清单完整（代码/文档/培训/运维手册/测试报告）
- [ ] 源码托管（Escrow）条款已加入（或替代方案）
- [ ] 性能指标写入合同（并发/延迟/可用率/数据量上限）
- [ ] 数据安全和隐私保护条款符合数据安全法规个人信息保护法规
- [ ] 国产化合规承诺写入（尤其是国企/大型项目）
- [ ] 第三方软件/组件的许可合规性由供应商保证
- [ ] 关基保护特别条款（如适用）
- [ ] 技术支持和服务的响应时间、升级运行框架明确

**项目条款（6项）：**
- [ ] 项目实施计划作为附件（含WBS和关键里程碑）
- [ ] 人员配置要求写入（关键人员名单、资质、更换需客户方同意）
- [ ] 变更管理流程（特别是需求变更的评审和计价运行框架）
- [ ] 延期交付的违约金条款
- [ ] 培训计划（培训次数、人数、方式、材料）
- [ ] 知识转移计划（运维手册、架构文档、常见故障处理）

---

## 附：PoC项目计划模板

| 周次 | 日期 | 里程碑 | 任务 | 负责人 | 交付成果 |
|------|------|--------|------|--------|--------|
| W1 | 8.1-8.7 | PoC启动 | 启动会、环境部署、网络开通、数据对接 | 各方 | 环境就绪确认单 |
| W2 | 8.8-8.14 | TC-01开始 | 单点路口信控场景测试 | 供应商+客户交通工程师 | 场景1测试报告（初版） |
| W3 | 8.15-8.21 | TC-01完成+TC-02开始 | 场景1最终测试+场景2开始 | 供应商 | 场景1终版报告 |
| W4 | 8.22-8.28 | TC-02完成+TC-03开始 | 绿波协调+高峰压力测试 | 供应商 | 场景2终版报告 |
| W5 | 8.29-9.4 | TC-03完成+TC-04开始 | 事件应急场景 | 供应商 | 场景3终版报告 |
| W6 | 9.5-9.11 | TC-04完成+评估总结 | 最终测试、效果评估、数据归档 | PoC评估小组 | PoC综合评估报告 |
| W6+1 | 9.12 | 环境拆除 | 供应商拆除测试环境、归还数据 | 供应商 | 环境拆除确认单 |

**每日站会议程（15分钟）：**
1. 昨日完成什么？（各供应商1句话）
2. 今天计划做什么？
3. 遇到什么阻碍？
4. 需要谁协助什么？

**每周进度检查：**
- 每周五下午，各供应商提交周报+下周计划
- PoC评估小组核查各供应商进度是否一致（防止有的供应商"赶工"多测，不公平）
- 记录任何偏离PoC范围的行为

---

> **法律声明**：本手册受著作权相关法律法规保护，未经作者书面授权，禁止任何商业用途（包括但不限于转售、捆绑销售、商业培训、SaaS化服务）。
> **免责声明**：本手册提供的方法论仅供学习参考，不构成任何形式的专业意见。技术选型和采购决策应基于充分的技术验证、法律审查和商业谈判。
> **作者信息**：yinjianheng（殷健恒）| yinjianheng@foxmail.com | 微信：YJH-yinjianheng
