业务运营能力

business-operations-skills
分类商业
作者Alireza Rezvani
许可MIT
评分4.80/5
使用3.6K

业务运营 (Business Operations) —— 领域编排器

BizOps 层面关注的是内部：公司实际如何运行。该编排器会分叉对话上下文，将您的查询路由至六个子技能之一，然后向父线程返回一个精简的摘要。繁重的数据摄取（供应商目录、流程访谈、多文档 SOP 导入）将保留在分叉的上下文中。

何时调用

| 症状 | 路由至的子技能 |
|---|---|
| “工作在哪个环节等待时间最长？” | process-mapper |
| “该供应商是否达到了 SLA 要求？” | vendor-management |
| “我们在第三季度有足够的人手交付吗？” | capacity-planner |
| “我需要向公司简报一次组织架构调整” | internal-comms |
| “为我编写一份事件响应流程的运行手册” | knowledge-ops |
| “为什么我们的软件支出同比增长了 40%？” | procurement-optimizer |

路由逻辑（确定性）

编排器通过在提示词中检测到的信号 (signals) 对查询进行分类。达到两个信号阈值则自信路由；一个信号则触发澄清问题。

信号表

| 信号类别 | 关键词 | 子技能 |
|---|---|---|
| 流程 (PROCESS) | bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow | process-mapper |
| 供应商 (VENDOR) | vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal | vendor-management |
| 容量 (CAPACITY) | headcount, capacity, utilization, planning, hiring sequence, FTE | capacity-planner |
| 沟通 (COMMS) | all-hands, internal newsletter, announcement, change management, FAQ, town hall | internal-comms |
| 知识 (KNOWLEDGE) | SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc | knowledge-ops |
| 采购 (PROCUREMENT) | spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl | procurement-optimizer |

如果信号混合（例如“供应商 SLA + 支出审计”），先运行置信度最高的子技能，然后在随后的分叉轮次中链式调用第二个。

回退机制

如果没有信号类别的得分 $\ge 2$，请提出一个澄清问题，并列出最可能的两个候选子技能。不要在无把握的情况下盲目猜测。

工作流 (Matt Pocock 质询纪律)

源自 Matt Pocock 的 grill-with-docs 模式：先探索后提问，每轮仅提出一个问题并附带建议答案，深度优先遍历决策树，跟踪依赖关系，所有质疑必须锚定在已记录的规范 (references/) 中。

第一步 —— 提问前先探索

在提出任何澄清问题之前，请检查：

  • 用户的工作目录中是否已经包含一个流程...

是否有我们可以 grep 的站点地图、供应商目录、SOP 或组织架构图？
  • 咨询内容是否已经明确了分 lane（例如，“供应商 SLA 审查” $\rightarrow$ vendor-management，无需询问）？

  • 提到的文件名是否能明确分 lane（例如，procurement-Q3.csv $\rightarrow$ procurement）？

如果代码库能确定 lane，请静默路由。不要询问。

第 2 步 — 若仍不明确，提出一个带有建议答案的强制性问题

Matt 的原则：绝不捆绑问题。绝不默认询问“你怎么看？”。始终提供你的建议。

模式：

code
Q1/1: [明确指出两个候选 lane 的问题]
建议：[Lane X，因为 <来自信号表的单句理由>]


(确认，或覆盖？)

等待用户响应。然后再路由。在提出问题后的回合中，绝不要静默猜测。

第 3 步 — 分叉决策树遍历（仅当咨询跨 lane 时）

如果用户的咨询确实跨越了两个 lane（例如，“供应商 SLA + 支出审计” = VENDOR + PROCUREMENT），请按深度优先遍历决策树：

1. 先解决置信度较高的 lane $\rightarrow$ 在分叉上下文中运行该子技能 $\rightarrow$ 返回摘要。
2. 询问：“现在是否应该运行 [第二个 lane]？我的建议是：是，因为 [依赖原因]。”
3. 仅在用户明确确认后，运行第二个子技能。

不要静默链式执行。每次分叉都必须是经过用户明确确认的步骤。

第 4 步 — 在分叉上下文中调用子技能

每个子技能在调用时需携带原始提示词 + 结构化输入（文件路径、JSON 输入）的摘要。分叉机制可将繁重的数据摄入（供应商目录、流程转录、SOP 源文档）排除在父上下文中。

第 5 步 — 返回带有引用典籍挑战的摘要

子技能完成后，向父线程返回一个 $\le 200$ 字的摘要：

  • 分析内容
  • 前 3 项发现（每项需锚定参考文档引用 —— 例如，“Goldratt 的约束理论：优化瓶颈，而非非约束因素”）
  • 前 3 项后续行动（尽可能注明负责人）
  • 生成产出物的路径
  • 一个针对用户的引用挑战（grill challenge）：“您的价值增加比为 12%。精益典籍 (Womack & Jones 1996) 将 <15% 定义为浪费严重。阻碍流程重新设计的因素是什么 —— 政治、技术还是预算？”

随后父代理可以进行追问（每次追问将触发新的分叉调用）。

强制性问题库（基于文档的质询模式）

当用户提供的上下文足以进入某个 lane 时，编排器可以在调用子技能之前，就该 lane 内部的决策对其进行质询。每轮一个问题，且包含建议答案 + 典籍引用。示例：

  • PROCESS lane：“在映射之前：您拥有每个阶段的实测周期时间，还是仅有估算值？建议：坚持要求前 3 个最长阶段的实测数据。反模式 (Goldratt 1984)：映射估算值，导致优化错误的约束。”
  • VENDOR lane：“在评分之前：您的一级关键性阈值是什么 —— 按支出（$/年），还是按运营依赖度（供应商失效会导致收入中断）？建议：运营依赖度。反模式 (Gartner TPRM)：仅按支出分级会遗漏关键的低支出供应商，例如 Target 数据泄露事件中的 HVAC 供应商。”
  • CAPACITY lane：“在建模之前：您是在为利用率还是吞吐量做计划？建议：吞吐量 (Little's Law)。反模式 (DORA)：将利用率计划在 > 80% 会因排队效应摧毁吞吐量。”

在 lane 定义决策锁定之前，绝不运行子技能。

假设

前提条件

1. 用户代表员工人数 $\ge 10$ 人的组织（规模较小的组织不需要此功能界面）。
2. 用户拥有子技能所需的数据访问权限（流程文档、供应商列表、支出导出等），或接受该技能提供的模板化虚拟数据。
3. 用户需要确定性的、可重复的分析，而非 LLM 风格的散文描述。每个子技能仅提供基于 Python 标准库（stdlib）的工具。

非目标

  • 不是 ERP、供应商管理平台（如 Vendr, Tropic）或容量规划 SaaS（如 Float, Runn）的替代品。
  • 不在会话之间存储状态 —— 每次调用都是独立的。
  • Python 工具不调用外部 API（设计上仅限标准库）。

区分点

  • **business-growth/* —— 侧重于外部销售动作（CSM、销售工程、营收运营 RevOps）。BizOps 侧重于内部。
  • c-level-advisor/coo-advisor —— 侧重于 COO 的战略判断（“我们是否应该重组？”）。BizOps 侧重于战术执行（“这是包含瓶颈的流程图”）。
  • engineering/slo-architect —— 侧重于通过 SLO/SLI/错误预算实现的系统可靠性。process-mapper 侧重于业务流程的可靠性，而非系统可靠性。
  • engineering/llm-wiki —— 侧重于个人知识管理 PKM（Karpathy 模式）。knowledge-ops 侧重于公司级** SOP 编写。

输出产物

每个子技能至少产生一个产物（Markdown、CSV 或 JSON），并保存到用户的工作目录中。编排器将在摘要中显示文件路径。

反模式（避免这样做）

  • ❌ 为了“全面”而运行所有 6 个子技能 —— 应根据信号选择其一，返回摘要，由用户决定是否链式调用。
  • ❌ 自动批准供应商或流程变更 —— 仅呈现发现结果，由人工决策。
  • ❌ 在未询问的情况下编辑生产环境的流程文档 —— 应写入新文件并提出差异（diff）建议。
  • ❌ 跳过摘要步骤 —— 父上下文需要 $\le 200$ 字的摘要，而非子技能的完整输出。

参考资料

  • 战略级 COO 框架请参阅 c-level-advisor/coo-advisor
  • Path-B 构建模式：documentation/implementation/bizops-commercial-expansion-plan.md