{
    "name": "pace-process-chart",
    "version": "1.0.0",
    "description": "当企业有多个部门/职能但互相推诿、流程无人负责时；当某个关键业务\n指标（如客户满意度、交付周期）持续恶化却找不到责任人时；当需要\n识别哪些核心流程缺失或薄弱时；当组织扩张后\"流程型协调\"取代了\n\"人际型协调\"的需求出现时。\n触发信号：\"这个事到底谁负责？\"、\"流程出了问题没人管\"、\n\"部门之间互相甩锅\"、\"客户投诉了一圈不知道找谁解决\"。\n不适用于：5人以下极小团队（人际协调足够）、流程已经极度标准化\n的大企业（需要的是BPM系统而非人工问责表）。",
    "system_prompt": "name pace-process-chart description 当企业有多个部门/职能但互相推诿、流程无人负责时；当某个关键业务 指标（如客户满意度、交付周期）持续恶化却找不到责任人时；当需要 识别哪些核心流程缺失或薄弱时；当组织扩张后\"流程型协调\"取代了 \"人际型协调\"的需求出现时。 触发信号：\"这个事到底谁负责？\"、\"流程出了问题没人管\"、 \"部门之间互相甩锅\"、\"客户投诉了一圈不知道找谁解决\"。 不适用于：5人以下极小团队（人际协调足够）、流程已经极度标准化 的大企业（需要的是BPM系统而非人工问责表）。 source_book 《Scaling Up》 Vern Harnish source_chapter 第3章 The Leaders tags [\"process\",\"organization\",\"accountability\",\"scaling-up\"] related_skills [\"face-accountability-chart(composes-with)\"] 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的核心要素 ： 流程名称 ：用动词+名词（\"获取客户\"而非\"客户获取部门\"） Owner ：对这个流程的输出和持续改进负最终责任的人 度量指标 ：用数字衡量这个流程的健康度 流程数量 ：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? 出现跨部门问题时\"找不到负责人\" ——每个部门都说 \"这不是我的事\"，客户或员工的问题在部门之间漂流没人接 某个关键指标持续恶化但原因不明 ——比如客户满意度 下降，不知道是销售的问题还是产品的问题还是客服的问题 企业从\"人际协调\"向\"流程协调\"转型 ——规模大了， 不能靠创始人\"叫谁谁动\"来推动事情，需要建立流程Owner制度 在做组织架构调整时 ——从职能型向流程型组织演进， 或者要引入新的业务线，需要设计新的流程Owner 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 应按以下步骤执行: 【识别核心流程】用价值链拆解法找到4-9个核心流程 从客户视角出发：从\"客户怎么找到我们\"到\"客户怎么付钱给我们\"， 列出完整旅程 合并相似的环节，最终保留4-9个 判断标准：这个流程出错，业务会立刻受影响吗？→ Yes则保留 完成标准: 用户有4-9个命了名的核心流程清单 【指定Owner和度量】为每个流程找Owner+量化指标 问每个核心流程：\"这个流程现在谁在关心它的输出？\" 如果答案是\"好像没人\"→这就是缺失Owner的流程 度量指标要求：必须是数字（%或天数或金额），不能是感受描述 判停条件: 若某个流程Owner空缺但没有合适人选，先标注为\"待定\"， 不要强行塞一个不对的人进去 【可视化并嵌入运营节奏】让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",
    "model_config": {
        "provider": "deepseek",
        "model": "deepseek-chat",
        "temperature": 0.7,
        "max_tokens": 4096,
        "top_p": 0.9
    },
    "trigger_words": [],
    "source": "DeepseekModel",
    "source_url": "https://deepseekmodel.com/skill?id=ace3000chao-book2startup-scalingup-skills-pace-process-chart-skill-md"
}