# Company Operating System

> 当搭建公司运营机制、选型管理框架、设计会议节奏、建立权责体系或落地 OKR 时使用；产出含责权图、记分卡、会议节奏、IDS 议题解决、90 天 Rocks 的运营系统设计与 30 天落地清单；不适用于具体业务执行或单个职能的深度方案。触发词：EOS、Scaling Up、OKR、L10 会议、Rocks、记分卡、责权图、IDS、季度规划。

- Skill: `findscripter/company-operating-system` (Agent Skill)
- Install (CLI): `npx skillmds@latest add findscripter/company-operating-system`
- Raw SKILL.md: https://api.skillmd.com/api/skills/findscripter/company-operating-system/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: findscripter (https://skillmd.com/u/findscripter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/findscripter/company-operating-system

---

## 何时使用

当你需要把"公司如何运转"显性化、可改进时使用，典型场景：

- 初创/成长期公司要搭建运营机制，从无到有建立协作节奏
- 在 EOS（Traction）、Scaling Up（洛克菲勒习惯）、OKR-native、Holacracy、自定义混合之间做框架选型
- 同一类问题每周复现、会议低效、权责不清、季度目标总是滑坡
- 要落地 OKR、设计周例会与议题解决流程、建立 90 天 Rocks

核心判断：多数运营失调不是人的问题，是系统的问题。修好系统，人在系统里自然运转更好。

不该用的边界：

- 不替代具体业务执行方案（如某次销售打法、某个功能设计）
- 不替代单一职能的深度专业内容（财务建模、招聘流程细节等）
- 已有成熟运营系统且运转良好时，不要为改而改
- 不是组织架构图（org chart）工具——本框架关注"谁对结果负责"而非汇报线

## 步骤

分阶段落地，切忌一次性全上。

第一步：建责权图（1 个 2 小时工作坊）
1. 列出公司执行的所有职能
2. 每个职能指派唯一负责人，无例外
3. 找出空白（无人负责）与重叠（两人都以为自己负责）
4. 公布，变化时更新

第二步：定记分卡（领导团队对齐，约 1 小时）
- 先定 5～10 个每周指标，每个有负责人和单一周目标值

第三步：启动每周 L10 例会（无需准备，直接开始）

这三件事带来的协同提升，超过多数公司一年的努力。

后续按 references 的 90 天计划逐步补齐会议节奏、Rocks、沟通节拍。

## 指令

六大核心组件（任何框架都需要这六项）：

1. 责权图（Accountability Chart）——回答"谁对这个结果负责"
   - 每个职能仅一人负责（owns），可多人参与（works in）
   - 禁止共享负责：「Alice 和 Bob 都负责」等于无人负责
   - 早期一人可兼多席，但要写明；按季度复盘随规模调整

   结构示例：
   ```
   CEO
   ├── 销售 (CRO/VP Sales)
   │   ├── 入站管道
   │   └── 出站管道
   ├── 产品与工程 (CTO/CPO)
   │   ├── 产品路线图
   │   └── 工程交付
   ├── 运营 (COO)
   │   ├── 客户成功
   │   └── 财务与法务
   └── 人力 (CHRO/VP People)
       ├── 招聘
       └── 人力运营
   ```

2. 记分卡（Scorecard）——每周指标，非月度非季度
   - 5～15 个指标上限；每个有负责人 + 单一周目标值（一个数，不是区间）
   - 红/黄/绿状态，不写段落；周会只讨论红色项
   - 反模式：测一切。跟踪 40 个 KPI 是在"看"不是在"管"

   | 指标 | 负责人 | 目标 | 本周 | 状态 |
   |------|--------|------|------|------|
   | 新增 MRR | CRO | €50K | €43K | 🔴 |
   | 流失率 | CS Lead | < 1% | 0.8% | 🟢 |
   | 关键 bug | CTO | 0 | 2 | 🔴 |
   | 现金跑道 | CFO | > 18mo | 16mo | 🟡 |

3. 会议节奏（Meeting Pulse）——维持公司"心跳"

   | 会议 | 频率 | 时长 | 参与 | 目的 |
   |------|------|------|------|------|
   | 每日站会 | 每日 | 15 分 | 各团队 | 只讲阻塞 |
   | L10/领导同步 | 每周 | 90 分 | 领导团队 | 记分卡+议题 |
   | 部门评审 | 每月 | 60 分 | 部门+领导 | OKR 进展 |
   | 季度规划 | 每季 | 1～2 天 | 领导团队 | 定 Rocks、复盘战略 |
   | 年度规划 | 每年 | 2～3 天 | 领导团队 | 1 年+3 年愿景 |

   L10 固定议程（目标是每次开成 10 分满分）：
   1. 好消息 (5 分)——个人+业务
   2. 记分卡评审 (5 分)——只标红色
   3. Rock 评审 (5 分)——逐项 on/off track
   4. 客户/员工头条 (5 分)
   5. 议题清单 (60 分)——走 IDS
   6. 待办评审 (5 分)——上周承诺
   7. 收尾 (5 分)——给会议打 1～10 分，下次如何到 10

4. 议题解决 IDS（Identify, Discuss, Solve）——每议题最多 15 分钟
   - Identify：用一句话说清真问题（根因，非症状）
   - Discuss：相关事实+视角，限时；讨论开始重复就停
   - Solve：一个负责人、一个动作、一个截止日，写进待办
   - 反模式："先线下聊"（多半永不解决）；只讨论不决策；重开已决议题（除非有新信息）
   - 议题清单：领导团队持有，每周评审并修剪。一个议题挂满 3 次会还没讨论，要么不是真议题，要么太可怕没人敢碰——两者都值得关注

5. Rocks（90 天优先级）——每人/团队 3～7 件
   - 为什么 90 天：足够取得有意义进展，又短到逼真
   - 每人最多 3～7 个，超 7 个一个都做不成
   - 二元判定：完成或未完成，没有"60% 完成"
   - 季度规划时设定，每周评审 on/off track
   - 坏 Rock："改进销售流程"
   - 好 Rock："3 月 31 日前上线 Salesforce CRM，含完整管道阶段与周报"
   - Rock vs 待办：待办一个动作搞定；Rock 需 90 天持续投入

6. 沟通节拍（Communication Cadence）——谁、何时、以何形式获得什么信息
   - 全员：月度公司更新（书面+Q&A）；季度结果+下季优先级（全员大会）
   - 领导团队：每周记分卡（仪表盘）
   - 董事会：月度董事备忘
   - 投资人：月/季关键指标+叙事
   - 默认规则：内部信息犹豫要不要分享时——分享。沟通不足的代价永远高于过度沟通

框架选型速查（详见 references/os-comparison.md）：

| 如果你是… | 考虑… |
|-----------|-------|
| 10～250 人、创始人主导、运营混乱 | EOS / Traction |
| 雄心成长型、需严谨战略级联 | Scaling Up |
| 技术公司、工程文化、假设驱动 | OKR-native |
| 去中心化、扁平、高自治 | Holacracy（仅当你有耐心） |
| 都不太合适 | 自定义混合 |

## 示例

输入：一家 60 人的 SaaS 公司，创始人反映"每周开会但同样的问题一直反复，季度目标总滑坡，没人清楚谁负责客户流失"。

适配输出（30 天快启）：

1. 选型：60 人、创始人主导、运营混乱 -> 推荐 EOS/Traction
2. 责权图工作坊产出："客户流失"明确归 CS Lead 唯一负责，消除"销售和 CS 都管"的重叠
3. 记分卡定 6 个周指标（新增 MRR / 流失率 / 活跃用户 / 部署次数 / 关键 bug / 现金跑道），各有数字目标
4. 启动每周 L10，固定议程，60 分钟走 IDS 处理议题清单
5. 季度规划上为领导团队设 3～7 个公司级 Rocks，每人 3～7 个，二元判定，周会 on/off track 复盘

关键自检问题：
- "若问 5 位团队负责人本季度公司前三优先级，答案会一致吗？"
- "谁负责客户流失？能毫不犹豫说出名字吗？"
- "说一个能在周五就判断本周好坏的指标——我们在跟踪它吗？"

## 注意事项

保留以下硬约束（来自源框架）：

- 责权图禁止共享负责；记分卡 5～15 个指标、用单一数字目标；Rocks 每人硬上限 7 个、二元判定；IDS 每议题 15 分钟
- 常见失败模式：
  - 部分落地："做 OKR 但跳过每周检查"——半套系统比没有更糟，制造无问责的表演
  - 会议疲劳：在现有会议上叠加全套节奏——应替换会议而非新增
  - 指标过载：开局上 30 个 KPI——从 5 个起步，节奏稳了再加
  - Rock 膨胀：每人 12 个 Rock——当一切都是优先级，就没有优先级
  - 领导不遵守：领导团队跳过 L10 或不走 IDS——系统得到的尊重等于领导给它的尊重
  - 只年度规划不季度复盘：季度是任何有意义目标的最低复盘周期
- 与 C-suite 的连接：CEO 出愿景喂给 1 年计划和 Rocks；COO 拥有会议节奏与议题解决；CFO 拥有财务指标；CTO 拥有工程 Rocks 与技术指标；CHRO 拥有人力指标（流失、招聘速度）

## 互见

- references/os-comparison.md —— EOS vs Scaling Up vs OKR vs Holacracy vs 混合 全面对比
- references/implementation-guide.md —— 90 天落地计划
- 关联技能：lark-okr（飞书 OKR 落地）、lark-task（Rocks/待办跟踪）、lark-calendar（会议节奏排期）

---

采编自 alirezarezvani/claude-skills（MIT）。