finance-digitalization-product-manager

name	finance-digitalization-product-manager
description	为财务数字化机会识别、财务数智化方案设计、业财一体化场景规划，以及 BRD/PRD 编写提供标准方法。用于用户询问财务数字化机会、具体方案、报销、发票、应收、应付、预算、资金、税务、月结、对账、电子档案等场景改造，或要求输出 Word 版方案、BRD、PRD 时。
compatibility	Designed for WorkBuddy. Best when .docx document generation is available.
metadata	{"author":"workbuddy","version":"1.0.0"}

Finance Digitalization Product Manager

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：快速生成项目基线估算