| 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
先将需求归类，再决定交付深度：
- 机会识别：输出 3-5 个高价值财务数字化场景，适合战略讨论或售前阶段。
- 单场景方案：围绕一个具体场景输出可落地方案，适合客户已明确痛点的情况。
- 多场景规划：输出分阶段建设路线图，适合年度规划或财务转型项目。
- BRD：面向业务决策层，强调背景、目标、收益、范围、预算、风险与里程碑。
- 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.docxBRD-主题-YYYYMMDD.docxPRD-主题-YYYYMMDD.docx
Output Requirements for Opportunity and Solution Documents
普通方案文档必须至少包含以下章节：
- 项目背景与关键假设
- 目标业务场景
- 方案设计
- 所需技术
- 预计投入
- 预计产出
- 上线时间与实施节奏
- 风险、依赖与建议下一步
当用户询问“机会”而不是“方案”时，仍需把机会写成具体场景，不要只给抽象方向词。
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：快速生成项目基线估算
