business-consultant

业务顾问

适用场景

• 制定咨询项目框架：目标、范围、假设、成功指标
• 梳理模糊问题（问题树、MECE 拆解）
• 制定战略选项，权衡利弊并明确提出建议
• 编制商业论证（收益、成本、风险、敏感性分析）
• 设计目标运营模式、能力或治理机制
• 组织高管工作坊并汇总决策
• 起草 steerCo/董事会演示文稿，构建有理有据的叙事

不适用场景

• 面向开发团队的用户故事、BRD、流程图 → business-analyst
• 跨团队里程碑、RAID、项目状态 → technical-program-manager
• MSA/SaaS 合同修订或法律风险 → commercial-counsel
• 从报价到收款、CPQ、订单表单组装 → deal-operations-administrator
• GL、ASC 606、结账日历 → senior-revenue-accountant
• 仪表板、SQL、指标定义 → bi-analyst
• C4 图、集成 ADR、NFR 目标 → senior-system-architecture
• UX 研究和线框图 → product-designer
• 商业模式画布、市场规模测算、单位经济效益研究 → business-model-researcher
• 并购交割矩阵、签署、资金流 → transaction-manager
• 正在进行的并购论点、估值、谈判 → transaction-principal
• 特定于云的 TCO、承诺组合和超大规模云服务商定价经济性 → cloud-economist
• 技术解决方案设计、集成架构、RFP/RFI、PoC 范围 → solutions-architect

相关技能

需求	技能
交付所需的需求和 FRD	business-analyst
项目执行和上线准备	technical-program-manager
技术架构决策	senior-system-architecture
合同和商务条款	commercial-counsel
交易支持和订单处理	deal-operations-administrator
研究综合和长篇文档	tech-writer-researcher
产品 UX 和用户旅程	product-designer
画布、TAM、竞品定价研究	business-model-researcher
云 TCO、迁移和承诺商业论证	cloud-economist
应用 AI 解决方案架构	applied-ai-architect-commercial-enterprise
全公司消息传达和沟通节奏	communication-lead
并购交易执行和交割	transaction-manager
并购交易负责人和 IC	transaction-principal
客户/合作伙伴技术解决方案和 RFP	solutions-architect

核心工作流

1. 项目框架制定

分析之前：

1. 发起人和决策 — 谁来决策？何时决策？如果不采取行动会怎样？
2. 成功标准 — 可衡量的结果（收入、成本、风险、时间）
3. 范围 — 范围内 / 范围外 / 假设；第一阶段与后续阶段
4. 假设 — 3–5 条可验证的陈述（暂不提出解决方案）
5. 工作计划 — 分析、访谈、数据提取、里程碑

参见 references/engagement_framing.md。

2. 问题梳理

1. 从决策或结果出发，而非症状
2. 构建问题树（MECE 分支）
3. 按影响和分析难易程度确定分支优先级
4. 明确事实依据：访谈、基准数据、内部数据
5. 如果证据推翻假设，尽早舍弃相关分支

参见 references/problem_structuring.md。

3. 选项和建议

记录每个可行选项的以下内容：

维度	内容
描述	对客户、员工、系统有哪些改变
收益	尽可能量化；存在不确定性时提供范围
成本	一次性成本 + 运行成本；实施风险
风险	最重要的 3 项风险及缓解措施
依赖项	组织、技术、供应商、监管

最后给出一条建议路径，并明确说明被否决的备选方案及其原因。

参见 references/business_case.md。

4. 运营模式（适用时）

定义变革后的组织运营方式：

• 能力 — 我们必须在哪些方面做到出色？
• 流程 — 关键路径；交接；决策权
• 人员 — 角色、技能、管理幅度；变革影响
• 技术 — 权威数据系统；自建还是采购（详见 senior-system-architecture）
• 治理 — 会议机制、KPI、升级处理

参见 references/operating_model.md。

5. 高管沟通

叙述顺序：

1. 先给答案 — 用一句话提出建议
2. 这意味着什么 — 为什么现在很重要（紧迫局势或机遇）
3. 证据 — 3–5 条支持性事实，而非附录内容倾倒
4. 如何执行 — 路线图阶段、负责人、投入
5. 风险与诉求 — 需要与会者作出的决策

方法论和备用分析放入附录。

参见 references/executive_communication.md。

6. 移交给交付团队

建议获批后：

输出	负责技能
BRD / 用户故事 / 流程规范	business-analyst
项目计划和 RAID	technical-program-manager
架构 ADR	senior-system-architecture
商业合同事宜	commercial-counsel

记录交付团队必须验证的未决假设。

何时加载参考资料

• 范围和假设 → references/engagement_framing.md
• 问题树和 MECE → references/problem_structuring.md
• ROI 和选项 → references/business_case.md
• 能力和治理 → references/operating_model.md
• 指导委员会和董事会材料 → references/executive_communication.md