# Pace Process Chart

> 当企业有多个部门/职能但互相推诿、流程无人负责时；当某个关键业务 指标（如客户满意度、交付周期）持续恶化却找不到责任人时；当需要 识别哪些核心流程缺失或薄弱时；当组织扩张后"流程型协调"取代了 "人际型协调"的需求出现时。 触发信号："这个事到底谁负责？"、"流程出了问题没人管"、 "部门之间互相甩锅"、"客户投诉了一圈不知道找谁解决"。 不适用于：5人以下极小团队（人际协调足够）、流程已经极度标准化 的大企业（需要的是BPM系统而非人工问责表）。

- Skill: `ace3000chao/pace-process-chart` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ace3000chao/pace-process-chart`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ace3000chao/pace-process-chart/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ace3000chao (https://skillmd.com/u/ace3000chao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ace3000chao/pace-process-chart

---


# PACe Process Chart（横向流程问责表）

## R — 原文 (Reading)

> "The Process Accountability Chart (PACe) lists who is accountable for each of the four to nine processes that drive the business and how each process will be measured."
>
> — Vern Harnish, Scaling Up, 第3章 The Leaders

---

## I — 方法论骨架 (Interpretation)

PACe（流程问责表）是Scaling Up的组织设计核心工具之一。
它的本质是回答一个问题：**"如果这个流程出了问题，谁负责？"**

**两个前置概念**：

**FACe（功能问责表）**——纵向：按职能分（销售/市场/技术/财务等），
每个职能指定一个人和KPIs，保证"对的屁股坐在对的位置上"。

**PACe（流程问责表）**——横向：按流程分，从客户旅程或价值交付链的角度，
识别4-9个核心业务流程，为每个流程指定一个Owner和度量方式。

**为什么需要横向？**
功能分工解决"谁做什么"，流程问责解决"谁保证这个事真的发生"。
很多企业有清晰的职能划分（FACe OK），但流程经常"在夹缝中"——
每个部门都沾一点，但没有一个人对整体流程负责。

**PACe的核心要素**：
1. **流程名称**：用动词+名词（"获取客户"而非"客户获取部门"）
2. **Owner**：对这个流程的输出和持续改进负最终责任的人
3. **度量指标**：用数字衡量这个流程的健康度
4. **流程数量**：4-9个（太少=遗漏关键流程；太多=等于没有重点）

**4-9个核心流程的典型划分**（以服务业为例）：
- 获取客户 / 需求理解 / 方案交付 / 客户满意度 / 收款

---

## A1 — 书中的应用 (Past Application)

### 案例 1: 客户投诉"没人管"的问题
- **问题**: 客户投诉经过多个部门（销售→技术→客服→管理层），
  每个部门都觉得是其他部门的责任，客户等了3周没得到有效回应
- **方法论的使用**: 引入PACe——识别"客户服务"作为一个独立流程，
  指定Owner和SLA指标（如48小时内首次响应）。Owner有权调动跨部门资源
- **结论**: 问题不在于没能力，而在于没"责任人"——流程Owner补上了这个缺口
- **结果**: 客户响应时间从3周缩短到48小时

### 案例 2: 产品交付质量下降但找不到原因
- **问题**: 产品质量问题频发，销售怪技术，技术怪采购，
  采购怪供应商——循环甩锅，没有尽头
- **方法论的使用**: 用PACe识别"供应链质量"和"产品交付"两个流程，
  指定两个不同的Owner，用PPM（百万零件缺陷率）和准时交付率来量化
- **结论**: 量化指标让问题的根源浮出水面——
  原来是采购换了供应商，但质量验收流程没有同步更新
- **结果**: 问题在两周内定位并解决

### 案例 3: 流程过多导致的"形式主义"
- **问题**: 某企业有25个流程，每个流程都有Owner和KPI，
  但每个Owner只关注自己的指标，跨流程的衔接问题没人管
- **方法论的使用**: 作者指出PACe的原则是"4-9个"核心流程——
  25个流程等于没有优先级。将25个合并为7个核心流程
- **结论**: PACe的目的是"聚焦"而非"全覆盖"；
  不是给每个工作都找个爹，而是给最重要的价值链环节找个负责人
- **结果**: 执行效率和清晰度大幅提升

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. **出现跨部门问题时"找不到负责人"**——每个部门都说
   "这不是我的事"，客户或员工的问题在部门之间漂流没人接
2. **某个关键指标持续恶化但原因不明**——比如客户满意度
   下降，不知道是销售的问题还是产品的问题还是客服的问题
3. **企业从"人际协调"向"流程协调"转型**——规模大了，
   不能靠创始人"叫谁谁动"来推动事情，需要建立流程Owner制度
4. **在做组织架构调整时**——从职能型向流程型组织演进，
   或者要引入新的业务线，需要设计新的流程Owner
5. **FACe已经建立但执行仍然打折扣**——功能分工清晰了，
   但"部门之间的事"（handover/衔接）还是没人管

### 语言信号 (用户的话里出现这些就应激活)

- "这个流程到底谁负责？"
- "部门之间互相甩锅怎么办？"
- "客户投诉了一圈没人管"
- "我们流程很多但好像没什么用"
- "指标出问题了不知道找谁"
- "交棒的时候总是出问题"
- "要设一个COO还是设流程Owner？"
- "我们的问题是没人承担责任"

### 与相邻 skill 的区分

- 与 `FACe（功能问责表）` 的区别: FACe是纵向职能分工，
  回答"每个职能部门谁负责"；PACe是横向流程分工，
  回答"每个核心业务流程谁负责"。两者互补，企业同时需要
- 与 `4D Framework` 的区别: 4D是顶层思考框架；
  PACe是People/Demands维度在"Process"子领域的具体落地工具
- 与 `Rockefeller Habits` 的区别: Rockefeller Habits是高管层的
  会议/节奏习惯；PACe是执行层的流程责任设计。
  高管用Habits保证方向，流程Owner用PACe保证执行

---

## E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行:

1. **【识别核心流程】用价值链拆解法找到4-9个核心流程**
   - 从客户视角出发：从"客户怎么找到我们"到"客户怎么付钱给我们"，
     列出完整旅程
   - 合并相似的环节，最终保留4-9个
   - 判断标准：这个流程出错，业务会立刻受影响吗？→ Yes则保留
   - 完成标准: 用户有4-9个命了名的核心流程清单

2. **【指定Owner和度量】为每个流程找Owner+量化指标**
   - 问每个核心流程："这个流程现在谁在关心它的输出？"
     如果答案是"好像没人"→这就是缺失Owner的流程
   - 度量指标要求：必须是数字（%或天数或金额），不能是感受描述
   - 判停条件: 若某个流程Owner空缺但没有合适人选，先标注为"待定"，
     不要强行塞一个不对的人进去

3. **【可视化并嵌入运营节奏】让PACe成为日常管理的一部分**
   - 把PACe打印出来贴在墙上（物理可见性很重要）
   - 在季度战略会中回顾PACe：哪个流程的指标恶化了？为什么？
   - 完成标准: PACe在季度战略会上被正式使用，而不是做完就归档

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- **5人以下的极小团队**：人与人直接协调比流程协调更高效，
  PACe会制造不必要的官僚主义；等到"我管不过来了"再考虑
- **流程已经极度标准化的大企业**：需要的是BPM系统和技术自动化，
  不是人工问责表；PACe适合成长型企业的"人工流程"阶段
- **战略方向尚未清晰**：PACe的前提是"知道哪些流程重要"；
  如果企业还在探索方向，先做OPSP或7 Strata of Strategy

### 作者在书中警告的失败模式

- **Owner变成"会议召集人"而非"结果负责人"**：
  Owner需要对流程的输出结果负责，而不是负责组织流程评审会
- **让多个Owner共管一个流程**（"联合负责"）：
  等于没人负责，每个流程必须有且只有一个最终Owner
- **流程Owner在职能上低于流程参与者**：
  导致Owner有权无威，决策推不动

### 作者的盲点 / 时代局限

- PACe假设Owner具备跨职能协调的权力和地位，
  但对"如何培养这种人"缺乏具体方法论
- 对远程/分布式团队的流程Owner制度如何运作，
  没有提供足够的场景化指引
- 原书出版时（2014年）对"AI/自动化对流程Owner职责的影响"
  讨论不足

### 容易混淆的邻近方法论

- **RACI矩阵**: RACI是"谁参与了这个决策"的分析工具，
  回答的是决策权限问题；PACe是"谁对这个流程负责"的责任工具，
  回答的是持续运营问题
- **流程图/泳道图**: 流程图描述"事情怎么做"，
  PACe描述"谁保证这事被做成"——描述目的不同，不可替代
- **OKR**: OKR定义目标，PACe定义谁来实现目标；
  没有PACe的OKR是空中楼阁（没人知道谁来干），
  没有OKR的PACe是忙碌但不聚焦（做了但不知道做给什么目标）

---

## 相关 skills (阶段 3 填充)

- depends-on: [fac-e, 4d-framework]
- contrasts-with: [raci-matrix, flow-chart]
- composes-with: [rockefeller-habits, cash-conversion-cycle]

---

## 审计信息

- **验证通过**: V1 ✓
- **测试通过率**: N/A (待测试)
- **蒸馏时间**: 2026-04-26