# 01-业务需求识别与问题定义工作流

## 一、工作流总览

```
┌─────────────────────────────────────────────────────────────────────┐
│                  业务需求识别与问题定义工作流全景图                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │1.业务背景 │──>│2.现状调研 │──>│3.问题定义 │──>│4.目标设定 │        │
│  │ 与战略对齐 │   │ 与数据收集 │   │ 与根因分析 │   │ 与指标体系 │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│       │              │              │              │                │
│       v              v              v              v                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │5.需求规格 │──>│6.约束识别 │──>│7.优先级   │──>│8.需求确认 │        │
│  │ 化与文档   │   │ 与风险预判 │   │ 排序与路线图│   │ 与基线锁定 │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│                                                                     │
│  核心产物: 业务需求规格书(BRS) | 问题定义报告 | 需求优先级矩阵         │
└─────────────────────────────────────────────────────────────────────┘
```

## 二、适用场景

本工作流从**技术解决方案提供方**视角出发，指导如何系统化地识别交通业务需求、定义核心问题。适用于：
- 交通管理部门的数字化升级需求分析（信号优化/拥堵治理/安全管理）
- 交通运营企业的智能化改造需求调研（高速运营/公交调度/港口自动化）
- 新建交通基础设施的智慧化需求定义（新线路/新枢纽/新港区）
- 跨部门交通数据共享与协同业务需求梳理

## 三、前置条件

| 输入项 | 来源 | 说明 |
|-------|------|------|
| 行业背景知识 | SKILL.md 第一/二部分 | 15大交通模态+12大业务链路 |
| 组织战略文档 | 客户方提供 | 理解战略方向和投资优先级 |
| 现有系统清单 | 客户方IT部门 | 当前系统架构和技术栈 |
| 历史项目资料 | 客户方提供 | 过往项目的经验教训 |

---

## 四、详细步骤说明

---

### 步骤1：业务背景与战略对齐（第1周）

**目标**：理解组织的业务战略，确保数字化需求与战略方向一致。

**输入**：组织战略文档、行业分析报告
**输出**：战略对齐分析报告

**关键活动：**

| 活动 | 方法 | 产出 |
|------|------|------|
| 战略解读 | 阅读组织的五年规划/年度工作报告/董事会议题 | 战略主题清单 |
| 行业对标 | 同行业数字化转型成功案例对标（参考SKILL.md案例库） | 对标差距分析 |
| 模态确认 | 确定适用的交通模态（城市道路/高速/铁路/港口...） | 模态画像 |
| 战略-数字化映射 | 将业务战略目标映射到数字化能力需求 | 数字化需求初筛表 |

**战略对齐检查清单：**
- [ ] 组织的核心业务目标是什么？（安全/效率/成本/服务/合规）
- [ ] 数字化在组织战略中的定位？（核心驱动力/支撑工具/探索方向）
- [ ] 同行业领先者的数字化水平？（参考T-DMM成熟度基准）
- [ ] 本次需求的战略紧迫性？（监管驱动/竞争驱动/效率驱动/创新驱动）

---

### 步骤2：现状调研与数据收集（第1-2周）

**目标**：全面了解业务现状、系统现状和数据现状。

**调研方法矩阵：**

| 调研方法 | 适用对象 | 样本量建议 | 时间 | 产出 |
|------|------|:---:|:---:|------|
| 高层访谈 | CEO/CTO/业务VP | 3-5人 | 1h/人 | 战略期望与约束 |
| 业务骨干访谈 | 部门经理/业务专家 | 5-10人 | 1.5h/人 | 业务流程与痛点 |
| IT技术访谈 | CIO/IT经理/运维负责人 | 3-5人 | 1h/人 | 系统现状与技术约束 |
| 现场观察 | 操作员/调度员/外场人员 | 2-3天 | 全天 | 实际工作流与隐性需求 |
| 数据分析 | 业务数据/系统日志/KPI报表 | — | 1周 | 量化现状与趋势 |
| 文档审阅 | 业务流程文档/系统设计文档/运维手册 | — | — | 规范化现状 |

**现状评估框架（As-Is六维画像）：**

| 评估维度 | 评估要点 | 评分(1-5) |
|------|------|:---:|
| 业务流程成熟度 | 流程标准化程度/自动化率/异常处理能力 | /5 |
| 系统技术现状 | 系统架构/技术栈/技术债务/可扩展性 | /5 |
| 数据能力 | 数据采集/数据质量/数据治理/数据利用 | /5 |
| 组织与人才 | 数字化团队规模/技能结构/AI能力 | /5 |
| 安全与合规 | 网络安全/数据保护/合规达标 | /5 |
| 运维能力 | 监控/告警/变更管理/容灾 | /5 |

---

### 步骤3：问题定义与根因分析（第2-3周）

**目标**：从现象深挖到根因，定义可行动的业务问题。

**问题定义方法：5 Why + 鱼骨图 + 数据验证**

**问题定义模板：**

```
问题陈述：[一句话描述核心问题]
影响范围：[影响的业务域/用户/系统]
严重程度：[P0-严重/P1-重要/P2-一般]
发生频率：[持续/每日/每周/周期性]
根因分析：
  直接原因 → [表层]
  中层原因 → [流程/系统/人员]
  根本原因 → [战略/架构/数据/组织]
量化影响：[经济损失/效率损失/安全影响/用户影响]
```

**交通领域常见问题模式：**

| 问题域 | 典型现象 | 常见根因 | 数字化解决方向 |
|------|------|------|------|
| 拥堵治理 | 高峰期拥堵里程>X km | 信号配时落后/事件响应慢/数据盲区 | AI信控/事件检测/态势感知 |
| 安全事故 | 事故率>Y起/百万车公里 | 感知不足/预警缺失/联动断层 | 全息感知/风险预测/V2X安全 |
| 运维成本 | 养护费用年增>Z% | 计划性差/检测手段落后/资源错配 | 预测性养护/无人机巡检/数字孪生 |
| 数据孤岛 | 跨部门数据无法共享 | 标准不统一/权责不清/技术异构 | 数据中台/标准接口/数据治理 |
| 服务体验 | 公众投诉量大/NPS<X | 信息不对称/服务断点/交互落后 | MaaS/信息服务/一站式服务 |

---

### 步骤4：目标设定与指标体系（第3周）

**目标**：基于问题定义，设定可量化的改善目标和KPI指标体系。

**目标设定原则（SMART-R）：**
- Specific（具体）、Measurable（可衡量）、Achievable（可达）、Relevant（相关）、Time-bound（有时限）、Risk-aware（风险意识）

**交通数字化KPI指标体系：**

| KPI类别 | 核心指标 | 目标值示例 | 基线数据来源 |
|------|------|------|------|
| 效率提升 | 平均行程时间/延误指数/绿波带宽利用率 | 降15-20% | 浮动车/卡口/互联网地图 |
| 安全改善 | 万车事故率/交通事故死亡人数/事件响应时间 | 降10-30% | 交管事故记录/122报警 |
| 成本节约 | 养护成本/能耗成本/人力成本 | 降10-25% | 财务报表/运维系统 |
| 服务体验 | 公众满意度(NPS)/信息发布及时率/投诉量 | NPS+10 | 用户调研/客服系统 |
| 环境效益 | 碳排放量/油耗/新能源占比 | 降15-25% | 能耗监测/碳排放核算 |

---

### 步骤5：需求规格化与文档（第3-4周）

**目标**：将调研和分析结果转化为结构化的业务需求规格书(BRS)。

**BRS文档结构：**
```
1. 文档概述（版本/范围/术语/参考）
2. 业务背景与战略对齐
3. 现状描述（As-Is六维画像）
4. 核心问题与根因分析
5. 业务目标与KPI体系
6. 功能需求（按优先级：P0必须/P1应该/P2可以）
  6.1 核心业务功能
  6.2 辅助业务功能
  6.3 数据与报表需求
  6.4 集成与接口需求
7. 非功能需求
  7.1 性能需求（响应时间/并发量/吞吐量）
  7.2 可用性需求（SLA/容灾/RPO-RTO）
  7.3 安全需求（等保/关基/数据安全等级）
  7.4 可扩展性需求（未来3-5年增长预期）
8. 约束与假设
9. 验收标准
10. 附录（访谈记录/调研数据/参考文档）
```

---

### 步骤6：约束识别与风险预判（第4周）

**目标**：识别所有约束条件，预判可能的风险。

**约束分类框架：**

| 约束类型 | 典型约束 | 影响 |
|------|------|------|
| 预算约束 | 年度IT预算上限/资金来源限制 | 范围/技术路线/分阶段策略 |
| 时间约束 | 上线deadline/行业规范时限/窗口期 | 实施策略/并行度/MVP范围 |
| 技术约束 | 遗留系统兼容/技术栈限制/供应商锁定 | 架构选择/集成方案/技术路线 |
| 组织约束 | IT团队规模/技术能力/跨部门协同 | 自研vs外包/培训需求/变革管理 |
| 合规约束 | 安全标准/数据保护/行业管理要求 | 安全架构/数据治理/审计需 |
| 运营约束 | 运维团队7×24能力/灾备要求/SLA | 架构冗余/运维工具/外包策略 |

**风险预判矩阵（Top 10）：**

| 风险 | 可能性 | 影响 | 等级 | 缓解策略 |
|------|:---:|:---:|:---:|------|
| 需求变更频繁 | 高 | 中 | 🟡 | 敏捷迭代+MVP先行 |
| 数据质量不达标 | 高 | 高 | 🔴 | 数据质量评估前置 |
| 遗留系统集成困难 | 中 | 高 | 🔴 | 提前API评估+中间层 |
| 供应商交付延迟 | 中 | 中 | 🟡 | 里程碑+违约责任 |
| 技术选型失误 | 低 | 高 | 🟡 | 技术预研+PoC验证 |
| 团队能力不足 | 中 | 中 | 🟡 | 培训+外部顾问+知识转移 |
| 安全事件 | 低 | 极高 | 🟡 | 安全左移+渗透测试 |
| 运维复杂度超预期 | 中 | 中 | 🟡 | 可观测性设计+自动化 |

---

### 步骤7：优先级排序与路线图（第4-5周）

**目标**：基于价值/可行性/紧迫性对需求排序，制定分阶段路线图。

**优先级评估矩阵：**

| 需求编号 | 需求描述 | 业务价值(1-5) | 实施难度(1-5) | 紧迫性(1-5) | 优先级得分 | 建议阶段 |
|:---:|------|:---:|:---:|:---:|:---:|:---:|
| REQ-01 | [描述] | 5 | 3 | 5 | 8.3 | Phase 1 |
| REQ-02 | [描述] | 4 | 4 | 4 | 6.0 | Phase 1 |
| ... | ... | ... | ... | ... | ... | ... |

> **优先级得分** = (价值×2 + 紧迫性×1.5 - 难度×1) / 3

**路线图阶段规划：**

| 阶段 | 周期 | 目标 | 关键需求 | 预期成果 |
|------|:---:|------|------|------|
| Phase 1：速赢 | 0-6月 | 快速见效，建立信心 | 高价值+低难度 | 早期KPI改善 |
| Phase 2：核心能力 | 6-18月 | 构建核心平台能力 | 高价值+中难度 | 平台上线+核心场景 |
| Phase 3：深化拓展 | 18-36月 | 覆盖全场景+AI深化 | 中价值+中高难度 | 全链路数字化 |
| Phase 4：创新引领 | 36月+ | 前沿技术试点 | 前瞻性场景 | 行业标杆/创新成果 |

---

### 步骤8：需求确认与基线锁定（第5周）

**目标**：与所有相关方确认需求，正式锁定需求基线。

**需求确认检查清单：**
- [ ] 所有业务相关方已审阅并签字确认
- [ ] IT/数据/安全部门已确认技术可行性
- [ ] 财务/投资部门已确认预算可行性
- [ ] 需求优先级已达成共识
- [ ] 非功能需求(SLA/性能/安全)已明确量化标准
- [ ] 验收标准已定义并可测试
- [ ] 需求变更控制流程已建立

---

## 五、关键注意事项

### 5.1 交通业务特有要点

- **模态差异是关键**：城市道路、高速、铁路、港口的需求逻辑完全不同，不可套用模板
- **安全永远是第一优先级**：涉及行车/航班/列车安全的需求，必须设置最高的可靠性要求
- **多相关方协调**：交通项目通常涉及业务部门、IT部门、财务部门、行业管理部门甚至公安/应急等，需求对齐成本高
- **数据是最大瓶颈**：大多数交通项目的最大挑战不是技术，而是数据质量、数据标准、数据共享

### 5.2 常见反模式

| 反模式 | 表现 | 规避方法 |
|------|------|------|
| **需求镀金** | 追求功能大而全，远超实际需要 | 严格按价值/紧迫性排序，先做"必须有的" |
| **技术驱动** | 先选技术再找问题，削足适履 | 始终问题驱动：业务问题→技术方案 |
| **大屏优先** | 追求酷炫大屏而非实际业务价值 | 以业务用户的日常操作场景为中心设计 |
| **一次到位** | 试图在第一期解决所有问题 | 分阶段交付，每个阶段有独立价值 |

---

## 六、产出物清单

| 产出物 | 负责人 | 完成时间 | 接收方 |
|------|------|:---:|------|
| 战略对齐分析报告 | 业务分析师 | 第1周 | 项目发起人 |
| As-Is六维现状评估 | 业务分析师+技术架构师 | 第2周 | 项目团队 |
| 问题定义与根因分析报告 | 业务分析师 | 第3周 | 所有相关方 |
| 业务需求规格书(BRS) | 业务分析师 | 第4周 | 技术团队+相关方 |
| 约束与风险登记册 | 项目经理 | 第4周 | 项目管理办公室 |
| 需求优先级矩阵与路线图 | 业务分析师+项目经理 | 第5周 | 决策层 |
| 需求基线确认文档 | 项目经理 | 第5周 | 所有相关方(签字) |

---

> **版本**: V1.0 | **撰写日期**: 2026-07 | **适用项目**: 交通数字化技术方案需求识别阶段
