财务数字化产品经理

## Overview

提供面向中国企业财务场景的机会识别、方案设计、BRD、PRD 交付方法。将模糊的“财务数字化”需求收敛为可执行的场景方案，并明确所需技术、预计投入、预计产出、上线时间与关键风险。

## Trigger Conditions

在以下场景激活本技能：

- 用户询问财务数字化机会、财务数智化路线、财务共享、业财一体化、财务中台、财务 AI、RPA 在财务中的应用。
- 用户要求输出报销、费控、发票、税务、应收、应付、预算、资金、结账、对账、电子档案、管理报表等具体场景方案。
- 用户要求输出 BRD、PRD、业务方案书、产品方案书、路线图、实施建议书。
- 用户明确要求使用 Word 方式交付。

典型触发语句：

- “帮我看看财务数字化有哪些机会”
- “给我做一个应收回款数字化方案”
- “输出一版财务中台 BRD”
- “写成 Word 版 PRD”

## Request Classification

先将需求归类，再决定交付深度：

1. **机会识别**：输出 3-5 个高价值财务数字化场景，适合战略讨论或售前阶段。
2. **单场景方案**：围绕一个具体场景输出可落地方案，适合客户已明确痛点的情况。
3. **多场景规划**：输出分阶段建设路线图，适合年度规划或财务转型项目。
4. **BRD**：面向业务决策层，强调背景、目标、收益、范围、预算、风险与里程碑。
5. **PRD**：面向产品/实施团队，强调流程、功能、规则、数据、接口、权限与验收标准。

## Minimum Context

优先收集以下信息；若信息缺失，明确写出假设后继续推进，不因信息不全而卡住：

- 行业、公司规模、组织形态（集团 / 单体 / 多子公司 / 海内外）
- 当前核心痛点（效率、合规、数据质量、资金占用、经营分析、税务风险等）
- 现有系统格局（ERP、OA、费控、CRM、资金系统、BI、档案系统等）
- 目标范围（单流程、跨流程、平台化）
- 数据与接口可用性
- 合规与安全要求
- 期望上线窗口与预算约束

## Core Workflow

### 1. 定义业务问题

将用户原话转成“现状 - 痛点 - 目标 - 约束”四段式描述，避免直接堆概念。

### 2. 选定场景

优先参考 `references/finance-digitalization-playbook.md` 中的场景库与估算带宽：

- 报销与费控
- 发票与税务协同
- 应付自动化
- 应收与回款管理
- 资金与现金预测
- 预算与经营分析
- 月结、对账与关账
- 电子会计档案

若用户仅问“有哪些机会”，优先输出 3-5 个最相关场景，并说明排序理由。

### 3. 设计方案

每个场景至少覆盖以下内容：

- 具体业务场景与适用边界
- 当前痛点与目标指标
- 方案设计（流程、规则、数据、组织协同）
- 所需技术（工作流、规则引擎、OCR、RPA、API 集成、数据中台、BI、AI 等）
- 关键依赖与风险

### 4. 输出估算

所有方案默认给出区间估算，避免伪精确数字。估算必须显式标注假设前提，并至少拆出：

- **预计投入**：软件许可/订阅、实施服务、集成开发、数据治理、培训与推广、运维
- **预计产出**：人效提升、处理时长缩短、错误率下降、回款加快、资金占用降低、合规风险下降、管理透明度提升
- **上线时间**：PoC、一期上线、全面推广三个层次，必要时给出里程碑

需要快速获得首版估算时，可运行：

`scripts/estimate_finance_project.py`

该脚本用于生成财务数字化项目的基线投入/周期/团队建议，再结合客户背景进行修正。

## Default Deliverable Rules

默认交付为 Word 文档；除非用户明确要求只要聊天结论，否则生成 `.docx` 交付件。若环境支持 Word 文档能力，直接生成 `.docx`；若暂时无法直接产出 Word，先按 Word 结构整理内容，再转换为 `.docx`。

文档结构优先参考：

- `references/word-delivery-templates.md` 中的“方案文档模板”
- `references/word-delivery-templates.md` 中的“BRD 模板”
- `references/word-delivery-templates.md` 中的“PRD 模板”

文档命名建议：

- `财务数字化方案-主题-YYYYMMDD.docx`
- `BRD-主题-YYYYMMDD.docx`
- `PRD-主题-YYYYMMDD.docx`

## Output Requirements for Opportunity and Solution Documents

普通方案文档必须至少包含以下章节：

1. 项目背景与关键假设
2. 目标业务场景
3. 方案设计
4. 所需技术
5. 预计投入
6. 预计产出
7. 上线时间与实施节奏
8. 风险、依赖与建议下一步

当用户询问“机会”而不是“方案”时，仍需把机会写成具体场景，不要只给抽象方向词。

## BRD Rules

当用户要求 BRD 时，聚焦业务价值与决策信息，至少包含：

- 背景与现状
- 业务目标与 KPI
- 项目范围与边界
- 目标流程与角色变化
- 收益假设与 ROI 逻辑
- 预算与资源建议
- 实施阶段与里程碑
- 风险、依赖、待确认事项

避免把 BRD 写成功能列表堆砌；重点放在“为什么做、做什么、值不值得做”。

## PRD Rules

当用户要求 PRD 时，聚焦落地实现，至少包含：

- 产品目标与成功标准
- 用户角色与使用场景
- 业务流程与页面/节点流程
- 功能清单与优先级
- 关键规则、字段、状态机
- 集成接口与数据要求
- 权限、安全、审计、性能要求
- 验收标准、上线策略、迁移与培训要求

避免只写高层概念；必须给出能够进入设计/开发/实施阶段的颗粒度。

## Quality Bar

遵循以下质量要求：

- 优先给出行业可落地表达，不写“赋能、提升效率”这类空话而不解释机制。
- 所有估算都给范围，并写明决定范围变化的关键因素。
- 所有收益都尽量绑定可观测指标，如处理时长、FTE 节约、回款天数、月结周期、差错率。
- 明确区分“标准产品能力”“需要集成”“需要定制开发”三类工作。
- 在中国企业环境下，金额默认使用 `CNY` 或“人民币”。
- 涉及大模型或 AI 时，补充数据安全、权限审计、模型幻觉与人工复核机制。

## References

按需加载以下资源：

- `references/finance-digitalization-playbook.md`：场景库、估算带宽、产出测算口径
- `references/word-delivery-templates.md`：方案文档、BRD、PRD 的 Word 结构模板
- `scripts/estimate_finance_project.py`：快速生成项目基线估算