06 · 八项交付物模板¶

用途：第 4 周整理输出阶段，照着这份模板填空。 核心心法：交付物的价值不在"漂亮"，在结构化、可执行。 使用说明：直接复制对应章节到 Word/飞书文档，把示例数据替换成真实数据。

八项交付物清单¶

序号	名称	模板章节	主要受众
①	现有系统数据源分析报告	§1	架构师、IT
②	目标数据钩稽关系图	§2	开发、架构师
③	人机结合点优化建议	§3	业务部门、UX
④	预警规则矩阵	§4	开发、运维
⑤	自动推算规则定义表	§5	开发
⑥	决策驾驶舱指标库	§6	前端、业务
⑦	版本管理规范	§7	开发、运营
⑧	需求规格说明书 V2.0	§8	开发、测试、甲方

§1 现有系统数据源分析报告¶

文档结构¶

1. 摘要
2. 分析范围与方法
3. 数据库结构概览
4. 核心报表血缘分析（按报表逐张）
5. 全局数据质量问题
6. 二期重构建议
7. 附录

1.1 摘要章节模板¶

## 摘要

本报告对一期业财一体化系统进行了为期 5 个工作日的逆向分析，
覆盖 X 张数据库表（共 Y 个字段）、Z 张核心报表。

### 关键发现 Top 5

1. **假数据源问题严重**：核心 20 张报表中，X 张存在"假数据源"
   （字段在报表显示但无法追溯到原始业务单据）。占比 X%。

2. **同一指标多版本**：识别出 X 个关键指标在不同报表中数值不一致，
   例如"已确认营收"在 3 张报表中分别取自 3 个不同源头。

3. **数据流断点**：X 个本应自动联动的业务事件实际上需要人工触发
   （如：合同变更→计划调整）。

4. **孤儿数据**：发现 X 张表、Y 个字段在所有核心报表中均未使用。

5. **性能瓶颈**：X 张核心报表生成耗时 > 1 分钟，根本原因为
   缺少索引 / 跨库 JOIN / 实时聚合。

### 重构优先级

| 优先级 | 范围 | 说明 |
|---|---|---|
| P0 必改 | X 项 | 涉及假数据源、指标多版本 |
| P1 应改 | X 项 | 涉及数据流断点 |
| P2 可改 | X 项 | 性能、可用性提升 |

1.2 单张报表血缘分析模板¶

## 4.1 营收汇总表

### 基本信息
- 报表 ID：RPT_REVENUE_001
- 主用户：财务总监、副总
- 使用频率：月度
- 数据范围：单位、部门、项目层级
- 性能：单次生成 X 秒
- 取数 SQL：附件 A1.sql

### 字段血缘表

| # | 报表字段 | 来源表.字段 | 计算逻辑 | 原始事件 | 数据质量 | 标记 |
|---|---|---|---|---|---|---|
| 1 | 项目编号 | `t_project.project_no` | 直接 | 项目立项时录入 | 一致 | ✅真 |
| 2 | 合同金额 | `t_contract.total_amount` | 按项目 SUM | 合同登记时录入 | 一致 | ✅真 |
| 3 | 已确认营收 | `t_revenue.confirmed_amount` | SUM(status='CONFIRMED') | 不明，疑似手工导入 | **每月人工覆盖** | ⚠️假 |
| 4 | 完工进度 | `t_project_extend.completion_rate` | 直接 | 每月由项目经理填 | 缺失率 30% | ⚠️疑 |
| 5 | 应收账款 | `t_finance_ar.balance` | 期末余额 | 从财务系统接口 | 与财务系统差异 < 1% | ✅真 |
| 6 | 剩余金额 | 派生计算 | 合同金额 - 已确认营收 | 计算 | 受字段 3 影响 | ⚠️假 |

### 数据质量问题汇总
1. **假数据源（字段 3、6）**：已确认营收实为每月人工从 Excel 覆盖式更新，
   与 `t_revenue_confirm` 业务单据无关联。剩余金额因依赖字段 3 同样不可信。
2. **数据缺失（字段 4）**：30% 项目未填完工进度，导致后续利润分析不准。
3. **跨系统差异（字段 5）**：业财之间应收账款有 1% 差异，未对账。

### 重构建议（W3 工作坊后回填）
1. **字段 3** 重构方案：建立 `t_revenue_confirm` 与验收单的自动联动。
2. **字段 4** 重构方案：完工百分比由系统按工时投入自动计算，废除手工填报。

1.3 全局问题章节模板¶

## 5. 全局数据质量问题

### 5.1 假数据源清单

| # | 字段位置 | 表现 | 根本原因 | 影响范围 |
|---|---|---|---|---|
| 1 | 营收汇总表.已确认营收 | 数值与业务单据脱节 | 月末手工覆盖 | 4 张下游报表 |
| 2 | 项目利润表.分摊费用 | 公式不明 | 财务每月拍数 | 决策驾驶舱 |
| 3 | ... | ... | ... | ... |

### 5.2 同一指标多版本问题

| 指标名称 | 出现位置 | 数值差异 | 差异原因 |
|---|---|---|---|
| 已确认营收 | 报表A: t_revenue<br>报表B: t_project_extend<br>报表C: 财务系统接口 | A=B≠C | 取数源头不统一 |
| ... | ... | ... | ... |

### 5.3 数据流断点

| # | 应有联动 | 实际现状 | 影响 |
|---|---|---|---|
| 1 | 合同变更 → 计划调整 | 需运营手工通知项目部 | 计划滞后 3-7 天 |
| 2 | 验收单审批 → 收入确认 | 财务月末批量人工处理 | 营收滞后 |
| ... | ... | ... | ... |

### 5.4 孤儿表 / 字段

| 类型 | 名称 | 是否可下线 | 理由 |
|---|---|---|---|
| 表 | `t_legacy_xxx` | ✅ 可 | 一期遗留，无报表使用 |
| 字段 | `t_contract.field_xxx` | ⚠️ 待确认 | 无报表使用，但可能业务侧用 |
| ... | ... | ... | ... |

§2 目标数据钩稽关系图¶

文档结构¶

1. 目标数据流总览图
2. 核心实体定义
3. 钩稽规则清单
4. 数据流转 case 推演
5. 与现状的差异说明

2.1 数据流总览图（用 Mermaid / Visio）¶

graph LR
    A[合同登记] --> B[项目立项]
    B --> C[计划制定]
    C --> D[委托单下达]
    D --> E[工时投入]
    E --> F[成本归集]
    D --> G[产值确认]
    G --> H[收入确认]
    H --> I[应收账款]
    I --> J[回款]
    F --> K[项目利润]
    G --> K
    C --> L[预算下达]
    F --> M[预算执行]
    L --> M

2.2 核心实体定义表¶

| 实体 | 主键 | 关键字段 | 与上游关系 | 与下游关系 |
|---|---|---|---|---|
| 合同 (Contract) | contract_no | 客户、金额、阶段 | - | 1→N 项目 |
| 项目 (Project) | project_no | 类型、级别、负责人 | N→1 合同 | 1→N 委托单、1→1 预算 |
| 委托单 (WorkOrder) | wo_no | 任务、金额、状态 | N→1 项目 | 1→N 工时、1→1 验收单 |
| 验收单 (Acceptance) | acc_no | 验收金额、日期 | 1→1 委托单 | 1→1 收入确认 |
| 收入确认 (Revenue) | rev_no | 金额、期间 | 1→1 验收单 | 1→1 应收账款 |
| ... |  |  |  |  |

2.3 钩稽规则清单（关键）¶

| # | 上游事件 | 自动联动 | 联动规则 | 例外处理 | 责任人 |
|---|---|---|---|---|---|
| K01 | 合同登记 | 自动生成项目主数据 | 1 合同 = 1 项目（默认） | 合同含多子项目→人工拆分 | 项目管理部 |
| K02 | 项目立项 | 自动下达预算 | 按合同金额×预算比例（科目维度） | A 级项目人工编制 | 财务部 |
| K03 | 委托单完结 | 自动生成产值 | 产值 = 委托金额 × 完成率 | 完成率 < 100% 需人工确认 | 项目经理 |
| K04 | 验收单审批 | 自动生成收入确认 | 收入 = 验收金额 | 跨期收入需手工调整 | 财务（监督）|
| K05 | 收入确认 | 自动生成应收账款 | 1:1 对应 | - | 系统 |
| K06 | 实际回款 | 自动核销应收账款 | 按合同号匹配 | 多笔回款合并→人工核销 | 资金主管 |
| K07 | 计划升版 | 自动备份历史版本 + 重算预算 | 旧版本只读保留 | - | 系统 |
| ... |  |  |  |  |  |

2.4 数据流转 case 推演（关键）¶

针对几个典型场景，逐步演示数据流转过程：

### Case 1：标准设计项目（B 级）的完整生命周期

#### 步骤 1：合同登记
- 输入：合同号 HT2026001、客户 X、金额 500 万、3 阶段付款
- 系统动作：
  - 写入 `t_contract`
  - 自动触发 K01 → 创建项目 PRJ2026001
  - 自动触发 K02 → 下达预算（按 70% 计算成本上限 350 万）

#### 步骤 2：委托单下达
- 项目经理在系统中创建委托单 WO2026001 → 设计部
- 系统动作：
  - 写入 `t_work_order`
  - 关联项目 PRJ2026001
  - 通知设计部负责人

#### 步骤 3：工时投入与成本归集
- 设计部成员每周填工时
- 系统动作：
  - 写入 `t_timesheet`
  - 按工时×标准成本率自动累计到 `t_project_cost`

#### 步骤 4：第一阶段验收
- 客户验收第一阶段，验收金额 150 万
- 系统动作：
  - 写入 `t_acceptance`
  - 自动触发 K03 → 生成产值 150 万
  - 自动触发 K04 → 生成收入确认 150 万
  - 自动触发 K05 → 生成应收账款 150 万

#### 步骤 5：回款
- 客户付款 150 万
- 系统动作：
  - 写入 `t_payment`
  - 自动触发 K06 → 核销应收账款

#### 检验点
- 这一周期下来，业务侧产值、财务侧收入、资金侧回款全部对齐
- 报表"项目营收完成率" = 150/500 = 30% ✅

§3 人机结合点优化建议¶

文档结构¶

1. 总体原则
2. 自动化分级标准
3. 关键岗位的人机结合优化（按岗位）
4. 实施建议

3.1 自动化分级标准¶

## 2. 自动化分级标准

将每个业务步骤按"权责"和"判断"两个维度分为四级：

| 级别 | 说明 | 判断标准 | 举例 |
|---|---|---|---|
| **L1 全自动** | 系统直接完成，无需人工 | 规则明确、无主观判断、责任由规则承担 | 计算应收账款余额 |
| **L2 半自动**（系统主导） | 系统计算+人工确认 | 规则明确但金额大、错误影响大 | 自动生成收入确认（人工确认）|
| **L3 半自动**（人工主导） | 人工操作+系统校验 | 需要业务判断，但系统辅助校验 | 项目立项审批 |
| **L4 全人工** | 人工完成，系统仅留痕 | 必须人工判断/责任、规则模糊 | 合同变更原因记录 |

3.2 关键岗位的优化（按岗位）¶

## 3.1 营收会计岗

### 现状分析（来自跟岗）
- 每月花在 Excel 上的时间：约 40 小时
- 系统外维护"影子事项簿"：14 项
- VLOOKUP 链长度：5 个 Excel
- 出错返工次数（月）：2-3 次

### 痛点根因
1. 收入确认依赖手工触发，未与验收单联动
2. 多个 Excel 维护同一数据，对账靠人工 VLOOKUP
3. 项目/合同/客户主键未在系统中统一

### 优化建议

| 步骤 | 现状级别 | 建议级别 | 优化说明 |
|---|---|---|---|
| 收到验收单通知 | L4（邮件） | **L1（自动）** | 业务侧审批通过自动通知 |
| 核对验收金额与合同 | L4（人工 VLOOKUP）| **L2（系统比对）** | 系统自动比对，超差异阈值人工干预 |
| 录入收入确认 | L4（手工录入）| **L2（自动生成+人工确认）** | 验收单触发自动草稿，会计确认提交 |
| 与应收账款挂账 | L3（手工选择）| **L1（自动）** | 合同号匹配自动挂账 |
| 与税务系统对接 | L4（手工汇总）| **L2（自动汇总+人工审）** | 自动生成纳税申报草稿 |

### 预期收益
- 月度工作量减少 70%（40h → 12h）
- 出错率降低 80%
- 月结提前 2-3 天

### 实施风险
- 会计可能担忧"系统出错谁负责"——需明确：自动生成的数据，会计**确认即承担责任**，与现在手工录入责任一致
- 历史 Excel 数据迁移工作量大——建议保留双轨过渡 1 个月

§4 预警规则矩阵¶

文档结构¶

1. 预警体系总览
2. 预警规则矩阵（核心）
3. 规则补充说明
4. 运维要求

4.1 预警体系总览¶

## 1. 预警体系总览

### 风险分类
- 财务风险（5 条）
- 项目风险（6 条）
- 资源风险（3 条）
- 合规风险（4 条）

### 等级定义
| 等级 | 颜色 | 推送时效 | 处置时效 |
|---|---|---|---|
| 红色 | 🔴 | 立即 | 24 小时 |
| 橙色 | 🟠 | 当日 | 3 工作日 |
| 黄色 | 🟡 | 次日 | 5 工作日 |

4.2 预警规则矩阵（主表）¶

| ID | 风险类型 | 触发条件 | 数据来源 | 阈值 | 等级 | 推送对象 | 推送方式 | 闭环要求 |
|----|---|---|---|---|---|---|---|---|
| W001 | 项目超预算 | 已发生成本/预算 >= X% | t_project_cost + t_budget | 90%/100%/110% | 黄/橙/红 | 项目经理→部门负责人→财务总监 | 系统消息+短信(红色) | 24h 提交处置方案 |
| W002 | 应收逾期 | 应收账龄 >= X 天 | t_finance_ar | 30/60/90 天 | 黄/橙/红 | 项目经理+财务 | 系统消息 | 7 天内联系客户 |
| W003 | 现金流紧张 | 30 天内付款计划/可用资金 >= X | t_payment_plan + t_cash_balance | 70%/85%/100% | 黄/橙/红 | 资金主管→财务总监→副总 | 系统+邮件 | 红色需开专题会 |
| W004 | 合同变更未处理 | 变更登记日 + X 天后未完成计划调整 | t_contract_change | 3/7/14 天 | 黄/橙/红 | 项目经理+计划员 | 系统消息 | 14 天必须闭环 |
| W005 | 工时未填报 | 上周工时填报率 < X% | t_timesheet | 90%/80%/70% | 黄/橙/红 | 部门负责人 | 系统消息 | 1 个工作日内补齐 |
| W006 | 项目进度偏离 | (计划进度-实际进度) > X% | t_project_milestone | 10%/20%/30% | 黄/橙/红 | 项目经理→部门负责人 | 系统消息 | 5 工作日提交补救方案 |
| W007 | 资源负荷过载 | 部门工时占用率 > X% | t_timesheet + t_dept_capacity | 90%/100%/110% | 黄/橙/红 | 部门负责人+运营总监 | 系统消息 | 评估外协必要性 |
| W008 | 集团报表临近 | 上报日期 - 当前日期 < X 天且数据未齐 | 内置 | 7/3/1 天 | 黄/橙/红 | 财务团队 | 系统+邮件 | 倒计时跟进 |
| W009 | 大额付款异常 | 单笔付款金额 > X 万 | t_payment_request | 100/500/1000 万 | 黄/橙/红 | 资金主管→副总 | 系统+电话 | 必须副总当面确认 |
| W010 | 业财数据差异 | 同一指标在两系统差异 > X% | 跨系统比对 | 1%/3%/5% | 黄/橙/红 | 财务+IT | 系统消息 | 24h 排查 |
| ... |  |  |  |  |  |  |  |  |

总计：≥ 15 条

4.3 闭环跟踪要求¶

## 3. 闭环跟踪要求

每条预警必须支持闭环跟踪：

1. **触发记录**：自动生成预警单
2. **响应跟踪**：处置人在系统内填写处置方案
3. **关闭确认**：上级或系统判断是否真正解决
4. **复盘统计**：月度统计响应时效、闭环率

### KPI 指标
- 红色预警 24 小时内响应率：≥ 95%
- 预警闭环率：≥ 90%
- 误报率：≤ 10%

§5 自动推算规则定义表¶

文档结构¶

1. 规则总览
2. 规则详细定义（逐条）
3. 数据依赖关系
4. 异常处理

5.1 规则定义模板（每条规则一份）¶

## 规则 R01：完工百分比自动计算

### 业务背景
设计项目周期长（1-5 年），按完工进度确认收入和产值。

### 计算公式

完工百分比 = MIN( 累计投入工时 / 预计总工时, 累计完成里程碑权重 / 总里程碑权重, 1.0 )

### 输入字段
| 字段 | 来源表 | 说明 |
|---|---|---|
| 累计投入工时 | t_timesheet | 项目所有人员工时 SUM |
| 预计总工时 | t_project.estimated_hours | 立项时设定，可调整 |
| 累计完成里程碑权重 | t_milestone.weight (status='DONE') | SUM |
| 总里程碑权重 | t_milestone.weight | SUM |

### 输出字段
| 字段 | 目标表 |
|---|---|
| t_project.completion_rate | 项目主表（覆盖更新） |

### 刷新触发器
- 工时录入触发：实时
- 里程碑状态变更：实时
- 计划升版：批量重算
- 定时兜底：每日 02:00

### 边界条件
- 公式取 MIN 是为了**防止完工率虚高**（如工时堆得多但实际没产出）
- 上限 1.0：防止超 100%

### 异常处理
| 异常 | 处理 |
|---|---|
| 预计总工时未设置 | 完工率为 NULL，报表显示"-" |
| 累计工时为 0 但有里程碑完成 | 完工率仅按里程碑算（异常情况，记录日志）|
| 完工率回退（如里程碑被退回） | 允许，但发预警通知项目经理 |

### 责任人
- 公式调整：财务总监 + 运营总监 共同决策
- 输入数据准确性：项目经理（工时）+ 项目管理部（里程碑）
- 系统计算正确性：IT 部门

### 测试用例
| 工时 | 总工时 | 已完里程碑权重 | 总权重 | 期望完工率 |
|---|---|---|---|---|
| 100 | 1000 | 20 | 100 | 10% |
| 500 | 1000 | 60 | 100 | 50% |
| 1100 | 1000 | 90 | 100 | 90% |
| 0 | 1000 | 50 | 100 | 0%（异常，需告警）|

5.2 8 条核心规则清单¶

| ID | 规则名称 | 公式简述 | 触发频率 | 优先级 |
|---|---|---|---|---|
| R01 | 完工百分比 | MIN(工时比, 里程碑比, 1.0) | 实时 | M |
| R02 | 非项目费用分摊 | 按部门人数分摊 | 月末批量 | M |
| R03 | 增值税进项 | SUM(已认证发票金额×税率) | 实时 | M |
| R04 | 增值税销项 | SUM(开票金额×税率) | 实时 | M |
| R05 | 上缴集团成本 | 营业收入×集团上缴率 | 月末批量 | S |
| R06 | 资金需求预测 | 未来 X 天付款计划 - 预期回款 | 每日 | M |
| R07 | 项目预算执行进度 | 已发生成本/预算金额 | 实时 | M |
| R08 | 资源负荷率 | SUM(项目占用工时)/部门总工时 | 周度批量 | S |

§6 决策驾驶舱指标库¶

文档结构¶

1. 指标体系总览
2. 指标分层与角色
3. 指标详细定义
4. 可视化与下钻设计

6.1 指标分层（按角色）¶

## 2. 指标分层

### 一把手视图（单位副总 / 一把手）
- 6 个核心指标（首屏）
- 月度更新

### 财务总监视图
- 12 个财务指标
- 周度+月度

### 运营总监视图
- 10 个运营指标
- 周度

### 部门负责人视图
- 部门级指标（按部门）
- 周度

### 项目经理视图
- 项目级指标（按项目）
- 实时

6.2 指标详细定义（每个指标一份）¶

## I01：经营完成率

### 业务含义
反映年度经营目标完成情况

### 计算口径

经营完成率 = 累计已确认收入 / 年度收入目标 × 100%

### 数据来源
- 累计已确认收入：t_revenue.confirmed_amount SUM
- 年度收入目标：t_annual_target.revenue_target

### 刷新频率
每日 06:00

### 默认筛选
- 时间：当年年初至今
- 维度：全单位

### 可下钻路径
单位级 → 部门级 → 项目级

### 异常表现
- < 50%（年中）：红色，告警
- 50%-80%：黄色，关注
- > 80%：绿色

### 责任人
- 数据准确性：财务总监
- 目标设定：单位高层

6.3 一把手视图（首屏 6 指标）¶

| 序号 | 指标 | 当期值 | 同比 | 健康度 | 颜色 |
|---|---|---|---|---|---|
| I01 | 经营完成率 | 65% | +5% | 中 | 🟡 |
| I02 | 项目利润率 | 18% | -2% | 中 | 🟡 |
| I03 | 应收账款余额 | X 万 | +8% | 差 | 🔴 |
| I04 | 在建项目数 | X 个 | +3 | 优 | 🟢 |
| I05 | 资金可用余额 | X 万 | -5% | 中 | 🟡 |
| I06 | 集团上缴完成率 | 70% | - | 优 | 🟢 |

§7 版本管理规范¶

文档结构¶

1. 版本管理总则
2. 计划版本管理
3. 合同变更管理
4. 数据基线与回溯
5. 变更原因结构化字段

7.1 核心要求¶

## 1. 总则

### 设计原则
1. **不可篡改**：历史版本永久保留，不可删除
2. **结构化**：变更原因不能是自由文本，必须从枚举值选择
3. **可追溯**：任何时点的数据状态可重现
4. **基线锁定**：批准的版本作为"基线"，后续变更对照基线计算偏差

### 适用范围
- 项目计划（核心）
- 合同（含变更协议）
- 预算
- 重要主数据（项目、客户）

7.2 计划版本管理¶

## 2. 计划版本管理

### 版本号规则
- 主版本.次版本.补丁号（如 V1.2.3）
- 主版本：基线变更（需高层审批）
- 次版本：重要调整（部门负责人审批）
- 补丁号：小修小补（项目经理可改）

### 升版触发条件
| 触发原因 | 升版类型 | 审批层级 |
|---|---|---|
| 合同变更 | 主版本 | 部门负责人 + 财务 |
| 工期重大调整 | 主版本 | 部门负责人 |
| 范围扩大 | 主版本 | 部门负责人 + 运营 |
| 资源调配 | 次版本 | 部门负责人 |
| 内部优化 | 补丁号 | 项目经理 |

### 升版原因结构化字段
不允许自由文本。从下列枚举选择：

| 类别 | 枚举值 |
|---|---|
| 合同类 | 客户范围变更、客户工期变更、客户金额调整、客户主动取消 |
| 内部类 | 资源调配、技术方案调整、内部里程碑调整 |
| 外部类 | 政策变化、不可抗力、上游供应延迟 |

### 基线保留
- 升主版本时，**前一主版本自动锁定为基线**
- 基线只读，可查询
- 实际执行与基线的偏差自动计算

### 数据存储方式（重要）
- ❌ 不允许覆盖式更新
- ✅ 必须用版本表（version table）

§8 需求规格说明书 V2.0¶

文档结构（标准 SRS 结构）¶

1. 引言
   1.1 编写目的
   1.2 项目背景
   1.3 范围
   1.4 术语与缩略语
   1.5 参考文档

2. 总体描述
   2.1 项目概述
   2.2 用户角色
   2.3 假设与约束

3. 功能需求（核心）
   3.1 业务流程
   3.2 数据模型
   3.3 功能模块清单
   3.4 用例描述（每个用例 1 节）

4. 非功能需求
   4.1 性能
   4.2 安全
   4.3 可用性
   4.4 可扩展性
   4.5 合规

5. 数据需求
   5.1 数据流图
   5.2 数据字典
   5.3 钩稽规则
   5.4 自动推算规则
   5.5 数据迁移

6. 接口需求
   6.1 系统集成
   6.2 用户接口
   6.3 通讯接口

7. 实施建议
   7.1 优先级（MoSCoW）
   7.2 分期实施
   7.3 风险与缓解

8. 附录
   附录 A：现有系统数据源分析报告（链接）
   附录 B：目标数据钩稽关系图（链接）
   附录 C-G：其他交付物（链接）

8.1 用例描述模板（关键）¶

每个核心用例使用这个结构：

## UC-001：项目立项

### 用例信息
- 编号：UC-001
- 名称：项目立项
- 主参与者：项目管理部
- 涉及部门：财务、运营、IT
- 触发条件：合同登记完成
- 前置条件：合同状态 = 已签订
- 后置条件：项目主数据已创建、预算已下达、相关人员已通知

### 主流程

| 步骤 | 系统 | 用户 | 数据变化 |
|---|---|---|---|
| 1 | 接收合同登记完成事件 | - | 触发立项流程 |
| 2 | 自动创建项目主数据草稿 | 项目管理部审核 | t_project 草稿 |
| 3 | 项目管理部确认项目级别 | 选择 A/B/C | t_project.level |
| 4 | 系统按规则下达预算草稿 | 财务部审核 | t_budget 草稿 |
| 5 | 财务部确认预算 | 提交 | t_budget.status = 已批准 |
| 6 | 系统通知相关人员 | - | t_notification |
| 7 | 项目状态变为"执行中" | - | t_project.status = ACTIVE |

### 异常流程

| 异常 | 处理 |
|---|---|
| 项目级别需要修改 | 流程退回到步骤 3 |
| 预算需要调整 | 走预算变更子流程 |
| 合同未签订却要立项 | 走"假立项"特殊流程（需副总审批）|

### 业务规则引用
- BR-001：项目编号生成规则
- BR-002：项目级别判定规则
- BR-003：预算自动下达公式

### 钩稽规则引用
- K01：合同→项目
- K02：项目→预算

### 优先级
M（必须）

### 验收标准
- [ ] 自动创建项目时间 < 5 秒
- [ ] 项目编号唯一
- [ ] 预算下达时财务可看到来源数据
- [ ] 通知 5 分钟内到达

8.2 优先级（MoSCoW）¶

## 7.1 优先级排序

### M (Must have) - 必须
- UC-001 项目立项
- UC-002 合同登记
- UC-003 委托单管理
- UC-004 工时录入
- UC-005 收入确认
- UC-006 应收账款管理
- 钩稽规则 K01-K06
- 预算规则 R01、R07
- 驾驶舱指标 I01-I06
- 预警规则 W001-W005

### S (Should have) - 应该
- UC-007 计划版本管理
- UC-008 集团报表
- 钩稽规则 K07
- 自动推算规则 R02-R05
- 预警规则 W006-W010

### C (Could have) - 可以
- UC-009 移动端审批
- UC-010 智能助手
- 高级 BI 分析

### W (Won't have) - 暂不做
- 区块链合同存证（甲方曾提出，本期不做）
- AI 预测（数据基础不足）

交付物间的引用关系¶

现有系统数据源分析报告 ①
       ↓ (现状基础)
目标数据钩稽关系图 ②
       ↓ (引用)
人机结合点优化建议 ③ ← 跟岗记录
       ↓
预警规则矩阵 ④
       ↓
自动推算规则定义表 ⑤
       ↓
决策驾驶舱指标库 ⑥ ← 管理层访谈
       ↓
版本管理规范 ⑦ ← 运营访谈
       ↓
需求规格说明书 ⑧ (统合所有)

8 份文档不是平行的，是有依赖关系的。写 SRS 时必须能引用前 7 份。

下一步 → 附录 · 常见陷阱与对策