模板复用落地方案：管理层开展项目模板的数据分析案例解析

去年第三季度，我参与了一家约 1400 人规模软硬件混合研发企业的研发管理诊断。这家公司在项目管理平台里积累了 217 个项目模板，但按“被真实项目引用、且累计使用超过 3 次”这个口径去筛，真正活着的模板只剩 26 个，占比不到 13%。更值得玩味的是，当时管理层在季度经营会上讨论的议题是“模板数量要不要扩充到 300 个”，而不是“为什么 87% 的模板从来没人打开过”。这篇文章要讲的就是这件事：管理层如何用数据分析的方式，把一个看起来属于 PMO 执行层的“模板复用”问题，变成一场能拿数字说话的管理决策。

一、核心结论：模板复用的成败，取决于管理层盯的是“数量”还是“复用数据”

我先把结论摆出来，后面再用背景、误区、判断逻辑和真实案例逐个展开。这几个结论不是从方法论书里抄的，是我在四家不同规模组织里做模板治理、被一线骂过也被管理层质疑过之后，留下来的判断。

1. 模板数量是负债，不是资产

这是我踩过最贵的一个坑。2021 年我在一家 600 人的 SaaS 公司推行模板体系建设，半年内把模板从 40 个做到 180 个，还在内部刊物上做了一期“模板体系建设成果”的宣传。结果下一次做项目复盘数据时发现，新项目启动时平均要在模板库里翻 4 分钟才能找到能用的模板，有 31% 的项目干脆自己新建，绕开了模板库。

模板的边际价值在“被复用”那一刻才产生，在此之前每多一个模板，都是在增加检索成本和选择成本。一个 300 个模板、复用率 10% 的库，实际效率远低于一个 30 个模板、复用率 70% 的库。管理层如果只看模板绝对数量，看到的是虚假的繁荣。

2. 模板复用率必须拆成四个可测量指标

很多团队说“我们有复用率”，追问下去发现口径是“模板被打开过的比例”。这个口径毫无意义，因为打开不等于使用，使用不等于填完，填完不等于项目结果更好。我会把复用拆成四层：被引用率、字段完成率、二次使用率、结果相关性。

这四个指标对应四个不同的管理问题：模板是不是被看见了、被看见之后是不是被认真用了、用过之后是不是有人愿意再用、用了之后项目结果是不是真的更好。只有第四个指标能回答“模板复用的投入值不值”这个问题，而这恰恰是管理层唯一真正关心的。

3. 管理层介入的正确位置是季度评审，不是逐条审批

我见过两种极端。一种是管理层完全不看模板数据，把它当成 PMO 的自娱自乐；另一种是管理层逐条审批模板，每个模板变更都要走三层签字。前者导致模板库失控膨胀，后者导致模板更新速度跟不上业务变化，一线干脆在系统外面用离线文档。

我建议的位置是：管理层按季度看一次模板组合数据，做“保留 / 合并 / 退休”三类决策，把具体模板的内容设计权交还给业务线。管理层管的是模板组合的结构，而不是单个模板的字段。

二、背景与真实场景：一个 1400 人研发组织的模板失控过程

为了让后面的分析有落点，我先把背景讲清楚。这家公司的业务结构是“硬件产品线 + 嵌入式软件 + 云端平台”三条线并行，研发人员 1400 人左右，横跨 11 个部门。项目类型高度混杂：既有 18 个月周期的硬件整机开发，也有 3 周交付的客户定制需求，还有长期不结项的预研项目。

1. 失控的三个阶段

第一阶段是 2019 到 2020 年的“野蛮生长”。三条业务线各自在项目管理工具里建模板，谁有需求谁建，没有人审核，也没有命名规范。到 2020 年底模板数是 84 个，其中至少有 9 个模板名字里都带“标准研发流程”但内容完全不同。

第二阶段是 2021 年的“规范化运动”。当时的 PMO 负责人做了一件很对的事：把所有模板收归统一管理，统一命名规范，建立模板评审流程。但同时做了一件埋雷的事，只新建不清理，评审只审“能不能加”，不审“要不要删”。到 2022 年年中，模板数冲到 217 个。

第三阶段是 2022 下半年开始的“沉默式废弃”。一线发现模板库找不到东西，于是开始自发地复制老项目的结构来建新项目，模板库逐渐变成摆设。这个阶段最危险的地方在于：表面上没有任何报错，系统运行正常，模板数量还在增长，只有埋点数据才看得出真相。

2. 我拿到的原始数据

我进场时拿到的是三份导出数据：模板清单（217 条，含创建人、创建时间、所属部门、字段定义）、项目实例清单（过去 24 个月 936 个项目，含所用模板 ID、创建时间、结项状态）、字段填写记录（项目实例上的字段填充情况）。

这三份数据交叉之后，问题的形状立刻清晰了：过去 24 个月里，有 168 个模板从未被任何项目引用；被引用过的 49 个模板中，又有 23 个只在创建当月被引用过 1 次，之后再无使用；真正持续被复用的模板只有 26 个，而这 26 个贡献了全部项目实例的 78%。

这是一个典型的帕累托分布，但当时的组织完全没有意识到。用一句话概括：模板库的运行逻辑已经从“公共资产”退化成“个人笔记”。

3. 为什么管理层此前看不到问题

我专门问过当时的分管副总，她说得很坦诚：她每个月看到的报告是“本月新增模板 6 个，累计 217 个”，报告里没有任何一个数字告诉她有多少模板在被使用。平台的原生报表默认统计的是创建量和模板总数，而不是复用率和引用分布。

这不是某个平台的缺陷，而是整个行业报表设计的默认视角，工具天然倾向于展示“增长”，而不是展示“效率”。所以管理层要看的指标，往往必须自己定义，而不能指望工具默认给你。

三、拆解四个常见误区

在讲专业判断逻辑之前，我要先把四个我反复见到的误区拆开。这四个误区的共同特点是：它们听起来都很合理，而且在短期内确实能带来可展示的成果，所以特别容易被管理层接受。

1. 误区一：把模板数量当成管理成熟度

这个误区最普遍，也最容易被外部咨询和内部汇报共同强化。因为模板数量是个好看的数字：它易采集、易展示、易做同比，而且天然向上增长。相比之下，复用率是个会波动、会下降、需要解释的数字，没人愿意把它放进汇报 PPT。

我的判断是：如果一家公司的模板体系汇报里只有数量没有复用率，那这个体系大概率是失效的。验证方法很简单，随机抽 10 个模板，看过去 6 个月有没有被 3 个以上项目引用过。如果超过一半达不到，说明数量增长与真实使用已经脱钩。

2. 误区二：用行政手段强制套模板

发现问题之后，最常见的反应是“那就强制”。强制项目必须从模板创建、强制字段必填、强制走审批。我在一家公司见过这个做法的后果：字段是填了，但填的是“待补充”“见附件”“N/A”，字段完成率从数据上看从 91% 涨到 98%，但数据质量实际上是下降的。

这是古德哈特定律（Goodhart’s Law）在模板治理上的经典体现：当指标变成目标，它就不再是好指标。强制能提升填写率，但填写的动机从“帮我自己管项目”变成了“应付检查”，数据的可信度反而下降。

3. 误区三：只看创建量，不看二次复用

只统计“本月新增模板数”，等于只统计进货量而不统计销量。我在做数据诊断时会专门算一个指标叫“模板二次使用率”，定义为：一个模板在被首次引用之后 90 天内，是否被第二个不同项目引用。

这个指标的意义在于，它过滤掉了所有“一次性模板”，为某个特定项目定制的、用完即废的结构。通过二次使用率的筛选，我们在一家公司的 217 个模板里识别出 168 个从未被复用的模板，其中有 91 个甚至连创建者自己都没有在新项目中使用过。

4. 误区四：让 PMO 独自承担模板治理

这是我见过的最隐蔽的组织问题。模板治理被默认为 PMO 的职责，而 PMO 通常是执行层，没有权限决定“哪个业务线的模板应该被退休”。结果就是 PMO 做了一堆数据，但改不动任何东西，治理动作停留在报告层面。

我的判断是：模板的内容设计权归业务线，模板的组合决策权归管理层，模板的数据分析归 PMO。三者分开，治理才转得动。缺少管理层这一环，PMO 的分析就只是“提建议”，不会变成“做决策”。

四、专业判断逻辑：模板健康度四层评估模型

接下来我讲我自己在用的评估框架。它不是从任何方法论体系里搬来的，而是我在多次数据诊断中逐步收敛出来的。核心思路是：把“模板有没有用”这个模糊问题，拆成四个层层递进的、可以从系统数据里直接算出来的问题。

1. 第一层：存在性，模板是否被创建

这一层最基础，也是最没信息量的一层。它只回答“模板在不在”，统计口径是模板总数和期新增数。我不建议把它作为主要考核指标，但它是后续三层的分母。

在这一层，唯一值得做的判断是命名规范和归属治理。我在一家公司做过统计，217 个模板里有 38 个名称包含“标准”二字，但字段差异超过 40%。命名不含信息量，是模板库走向混乱的第一信号。

2. 第二层：引用性，是否被项目真实引用

这一层的核心指标是模板被引用率 = 统计周期内被至少一个项目引用的模板数 ÷ 模板总数。我通常用 90 天作为统计窗口，因为大部分研发组织的项目周期分布在这个量级。

在此基础上再加一个“引用强度”指标：单个模板被引用的项目数中位数。这两个指标配合使用，可以快速识别模板库的形状。如果一个库的引用率低于 30%，说明模板库的主要功能已经从“公共资产”退化为“个人存档”。

3. 第三层：完成性，引用之后字段是否被填满

这一层是大多数人会忽略的。项目引用了模板，不代表模板里的字段被认真填写了。我会统计两个指标：关键字段填写率、关键字段有效值率（排除“待补充”“N/A”“见附件”等占位值）。

在一次诊断中，我看到某类模板的字段填写率是 94%，但有效值率只有 51%。追问原因发现，模板要求填写“需求来源”和“验收标准”，但这两个字段在很多项目里确实无法在启动阶段确定，一线只能填占位符。这说明问题不在执行，而在模板设计与业务阶段不匹配。

4. 第四层：结果性，填满之后项目结果是否更好

这一层是管理层唯一真正关心的，也是最难算的。我的做法是做一个简单的分组对比：把使用过模板库中“健康模板”的项目分为 A 组，把未使用模板或使用非健康模板的项目分为 B 组，对比两组在计划偏差率、按期交付率、复盘数据完整度上的差异。

需要特别说明的是，这是一个相关性分析，不是因果分析。使用健康模板的项目可能本身就是管理更规范的团队做的。所以我通常只把结果作为“支持性证据”，而不是作为“证明模板有效”的铁证。如果 A 组和 B 组差异超过 15 个百分点，我会倾向于认为模板体系是值得继续投入的；如果差异在 5 个百分点以内，我会建议管理层的注意力转移到别处。

5. 判断阈值：什么算健康、什么该合并、什么该退休

我会给每个模板打一个四层得分，然后按下表做处置判断。这套阈值是经验值，不是行业标准，不同组织需要根据项目类型分布做调整，但结构可以复用。

五、案例解析：用 PingCode 做模板数据分析的实操过程

框架讲完了，接下来讲怎么落地。我在几个项目里用的数据底座是 PingCode，主要原因是它服务中大型企业、尤其是 100 人以上组织，这类组织的模板治理问题最典型，而且平台本身对私有化部署和 Jira 平滑迁移的支持，让很多正在做国产化替换的团队不用重复建设数据环境。下面的过程是我在实际项目里跑过的，数据做了脱敏和比例缩放。

1. 为什么选这个平台做数据底座

选它有三个具体理由，都不是“功能多”这种空话。第一，它的工作项模型和字段定义是结构化的，模板字段可以直接映射到数据库表，做交叉分析不用手工整理 Excel。第二，它支持私有化部署，对于研发数据敏感的中大型组织，数据可以直接在自有环境里做分析，不用考虑数据出域的合规问题。

第三，也是对我来说最关键的一点：它允许在项目实例上保留模板来源标识。很多工具在项目创建时会把模板“拍平”成普通配置，创建之后你就再也追溯不到这个项目是从哪个模板来的。没有这个追溯字段，模板复用分析根本做不了，这是我在选型阶段最看重的一个技术细节。

如果你所在的组织正在做 Jira 迁移，我建议在迁移方案里就明确保留模板来源标识，否则迁移完成之后你会发现模板治理的分析链路是断的。

2. 数据采集：模板、项目、字段、工时四张表的关联

我的数据采集脚本核心是四张表的关联：模板定义表、项目实例表、字段填写表、工时与状态变更表。四张表通过模板 ID 和项目 ID 串起来，就能算出前面提到的四层指标。下面是我实际用的取数逻辑，做了简化，用来说明思路。

-- 模板复用四层指标取数（简化示意）
-- 说明：字段名做了抽象，实际表名按平台的数据结构映射

WITH template_usage AS (

SELECT

t.template_id,

t.template_name,

t.creator_id,

t.created_at,

COUNT(DISTINCT p.project_id)              AS ref_project_cnt,

COUNT(DISTINCT p.owner_dept_id)           AS ref_dept_cnt,

MAX(p.created_at)                         AS last_ref_at,

MIN(p.created_at)                         AS first_ref_at

FROM template_def t

LEFT JOIN project_instance p

ON p.template_id = t.template_id

AND p.created_at >= DATE_SUB(CURRENT_DATE, INTERVAL 90 DAY)

GROUP BY t.template_id, t.template_name, t.creator_id, t.created_at

),

field_quality AS (

SELECT

p.template_id,

COUNT(*)                                                         AS field_total,

SUM(CASE WHEN f.value IS NOT NULL THEN 1 ELSE 0 END)             AS field_filled,

SUM(CASE WHEN f.value IS NOT NULL

AND f.value NOT IN ('待补充','N/A','见附件','TBD')

THEN 1 ELSE 0 END)                                      AS field_effective

FROM project_instance p

JOIN project_field_value f ON f.project_id = p.project_id

GROUP BY p.template_id

)

SELECT

u.template_id,

u.template_name,

u.ref_project_cnt,

u.ref_dept_cnt,

ROUND(f.field_filled * 1.0 / NULLIF(f.field_total, 0) * 100, 1)     AS fill_rate_pct,

ROUND(f.field_effective * 1.0 / NULLIF(f.field_total, 0) * 100, 1)  AS effective_rate_pct,

CASE

WHEN u.ref_project_cnt = 0                                   THEN '候选退休'

WHEN u.ref_project_cnt = 1 AND u.ref_dept_cnt = 1            THEN '观察期'

WHEN f.field_effective * 1.0 / f.field_total WHEN u.ref_project_cnt >= 3                                  THEN '核心模板'

ELSE '常规模板'

END                                                                 AS health_label

FROM template_usage u

LEFT JOIN field_quality f ON f.template_id = u.template_id

ORDER BY u.ref_project_cnt DESC;

这套逻辑跑一次大约需要几分钟，输出就是一张带健康标签的模板清单。我通常会把这张清单直接导出成一张表交给管理层，而不是做成复杂的可视化大屏。管理层要的是一个能直接在上面圈出“这几个退休、这几个合并”的决策清单，不是一堆需要解读的图表。

3. 分析过程与关键发现

第一次跑完数据之后，有三个发现超出了我的预期。

第一个发现是模板数量与字段数量呈负相关。模板越多，单个模板的字段定义反而越少、越粗糙。原因是新建模板的人为了快速通过审核，倾向于精简字段，导致新模板的功能反而弱于老模板。这意味着盲目扩张模板库不仅稀释了复用率，还在拉低单个模板的质量下限。

第二个发现是模板的引用集中在特定的时间点。有 34 个模板只在创建当月被引用，之后无人问津。进一步看，这些模板的创建者大多是当年的项目负责人，在项目结束后就再也没有更新过模板。这实际上是“项目经验未能转化为组织资产”的典型症状。

第三个发现，也是最反直觉的一个：模板字段数和字段填写完成率之间不是线性关系。字段数在 8 到 14 个之间时，填写完成率最高，达到 89%；字段数少于 8 个时完成率反而降到 76%，字段数超过 20 个时骤降到 43%。

我的解释是：字段太少时，模板无法覆盖项目管理的必要信息，一线觉得“这个模板没用”，于是敷衍了事；字段太多时，填写成本超过收益，一线开始批量填占位符。模板设计存在一个“甜点区”，而这个甜点区只能通过数据找出来，靠开会讨论是讨论不出来的。

4. 治理动作与三个季度的结果

拿到数据之后，我们做的治理动作其实不多，只有四件事，但每一件都需要管理层的签字授权。

1. 归档零引用模板。168 个从未被引用的模板全部归档，其中创建者已离职的 62 个直接删除，其余设置 180 天观察期。
2. 合并高重合模板。把字段重合度超过 70% 的模板做合并，从 49 个活跃模板合并到 31 个，差异部分做成可选字段组。
3. 为每个保留模板指定负责人。每个模板必须有一个业务线负责人和一个 PMO 对接人，负责人每季度至少检视一次模板的字段有效值率。
4. 把复用率纳入季度经营评审。不进个人绩效，但进管理层的季度看板，由 PMO 统一出数。

三个季度之后的结果：模板总数从 217 个降到 43 个，模板月复用率从 12.6% 升到 47.3%，新项目启动的平均耗时从 3.4 人天降到 1.1 人天。项目按期交付率从 61% 提升到 79%。

这里必须说一句常识：按期交付率的提升不能全部归功于模板治理，同期还做了需求管理和资源排期两件事。但如果把时间轴拉出来看，模板复用率的提升曲线与按期交付率的提升曲线之间有明显的时间领先关系，前者领先后者约一个季度。这个时间差本身就值得管理层注意。

5. 踩过的三个坑

过程不是一次成功的。我把三个坑列在这里，希望后来者少走弯路。

第一个坑是一次性清理太激进。我们第一轮把 168 个模板全部归档，结果两周内收到 11 个投诉，其中有 3 个模板确实在半年内会被某个长周期项目用到。后来的做法是：零引用模板先归档不删除，保留搜索入口，并在归档时通知创建者。

第二个坑是只按部门维度分析，漏掉了项目类型维度。硬件整机开发项目和客户定制项目的模板需求完全不同，早期把它们放在一起做复用率统计，得出的结论是误导性的。后期我们按项目类型分层统计，才发现硬件线的复用率其实一直健康，问题集中在客户定制线。

第三个坑是过度依赖字段填写率做考核。有一段时间字段填写率被写进了项目负责人的月度考核，结果出现了大量无效填写，字段有效性反而下降。我的结论是：填写率适合作为观察指标，不适合作为考核指标，一旦进考核，数据就会失真。

六、不同情况下的行动建议

上面的案例是 1400 人规模的组织。但不同规模、不同阶段的组织，做法完全不同。我按自己实际接触过的几类情况分开讲。

1. 组织在 100 人以下

这个规模我不建议做模板数据分析，因为样本量太小，统计上不显著。100 人以下通常是 10 到 30 个并行项目，模板数量一般在 10 个以内，靠人工判断就够了。

这个阶段该做的是把模板数量控制在 5 到 8 个，并且每个模板都有一个明确的负责人。我见过太多小团队一开始就建了 40 个模板，结果三个月后自己都记不清哪个是哪个。这个阶段唯一的量化动作是：每季度花半小时看一下哪些模板这季度被打开过，没打开的当场删掉。

2. 组织在 100 到 1000 人

这是模板治理投入产出比最高的区间。这个规模下，模板数量通常在 40 到 150 个之间，已经开始出现明显的“找不到”的问题，但还没有形成盘根错节的部门利益。

我建议的动作顺序是：先做一次全量数据体检，算出四层指标；再按健康等级做一次归档和合并；然后建立季度评审机制，把复用率纳入管理层看板。这套动作在一家 400 人公司里做了大约 6 周，其中数据分析占 1 周，其余时间是沟通和协调。

如果这个规模的组织正在做国产化替换，我建议把模板治理和迁移方案合并推进。PingCode 在这类场景里比较合适，因为它支持私有化部署，也支持从 Jira 平滑迁移，模板结构和历史项目的映射关系可以在迁移过程中一次性梳理清楚，比迁移之后再单独治理要省一半以上的力气。

3. 组织在 1000 人以上或多事业部

这个规模的组织，模板治理的难点不在数据分析，而在治理权限。我的建议是分两层：集团层管“模板分类框架和命名规范”，事业部管“本事业部的模板内容和字段设计”。数据分析由集团 PMO 统一做，出一份跨事业部的对比报告，按季度给到各事业部负责人。

一个具体的做法：集团层定义不超过 6 个模板大类（例如硬件开发、软件开发、客户交付、预研探索、运维支持、内部系统），每个大类下由事业部自行维护具体模板，但大类之间的模板不允许交叉引用。这个约束能把跨事业部的模板混乱控制在一个可管理的范围内。

4. 已有大量历史模板的存量组织

存量组织的核心矛盾是：清理成本和业务风险之间的平衡。我的建议是一定要设置观察期。零引用模板先归档不删除，保留搜索入口，观察 180 天。如果 180 天内确实无人检索，再正式删除。

另外建议按创建时间分批处理，优先处理 2 年以上的老模板，近 6 个月新建的模板先不动。原因很简单：新模板的复用数据还没跑出来，用 90 天窗口去判断新模板是不公平的。

5. 正在做国产化替换的组织

这类组织有一个特殊优势：旧系统的模板评估结果可以直接作为迁移筛选的依据，不需要先迁移再治理。我一般建议在迁移前先做一次模板健康度扫描，只迁移健康模板和待优化模板，僵尸模板和历史模板直接留在旧系统里做只读归档。

这样做的好处是迁移后的新系统天生干净，一线不会在第一次使用时就被几百个模板淹没。用 PingCode 做迁移时，这套思路比较好落地，因为它的模板和项目数据结构足够清晰，映射关系可以在迁移脚本里一次性定义好。

七、不同情况下的取舍

治理过程中一定会面对取舍。这一节我讲四组我认为最关键、也最容易做错的取舍。

1. 标准化程度与一线灵活性

这是模板治理的根本矛盾。标准化程度越高，跨项目数据可比性越强，管理层越容易做横向对比；但一线面对的实际情况差异巨大，过度标准化会逼着他们用离线文档绕过系统。

我的判断是：把标准化放在“字段名称和取值口径”上，把灵活性放在“字段是否必填”上。也就是说，字段的定义必须统一，但不同项目类型可以选择哪些字段必填、哪些选填。这样数据在跨项目分析时仍然可比，而一线也不会觉得被框死。

2. 模板颗粒度：粗与细

粗模板（字段少、约束松）的好处是接受度高，坏处是沉淀的数据不够用；细模板（字段多、约束严）的好处是数据完整，坏处是前面提到的甜点区问题，超过 20 个字段之后，有效填写率会大幅下降。

我的经验是：按项目类型分层设置颗粒度。长周期、高投入、需要复盘的硬件开发类项目，可以用 15 到 20 个字段的细模板；短周期、低投入的客户定制类项目，用 6 到 8 个字段的粗模板就够。全组织统一颗粒度是错误的目标。

3. 强制约束与引导推荐

前面讲过强制的问题。但在某些情况下强制是必要的：涉及合规、安全、财务核算的字段，必须强制。判断标准是：这个字段缺失会不会导致组织承担实质风险？会，就强制；不会，就推荐。

我通常会把模板字段分成三档：强制必填（合规类，通常不超过 3 个）、建议填写（管理类，模板默认展示但不拦截提交）、可选填写（分析类，折叠展示）。这个三档结构比“全必填”或“全选填”都更实用。

4. 自建分析体系与使用平台原生报表

这个取舍取决于你需要的分析维度有多复杂。如果只是看模板数量和引用次数，平台原生报表基本够用，没必要自建。但如果要做四层指标、跨表关联、项目结果对比，原生报表通常做不到，需要自己取数。

我的建议是：先用原生报表做 2 周快速摸底，如果发现关键指标取不到，再自建分析链路。自建分析的成本主要不在技术，而在数据口径的统一，你需要说服不同业务线接受同一套指标定义，这件事往往比写 SQL 花的时间长得多。

八、总结：模板复用的本质是“管理知识的版本管理”

回到最初的标题。管理层开展项目模板的数据分析，最容易被误解成一件技术活或统计活。但从我这几年的实践看，它本质上是把散落在各个项目里的管理经验，做成一套可以版本化、可以评估、可以淘汰的组织资产。

这套资产的健康度不体现在数量上，而体现在四个数字上：多少模板被真实引用、引用的模板有多少被认真填写、被认真填写的模板有多少被重复使用、被重复使用的模板有多少带来了更好的项目结果。这四个数字构成了一个完整的证据链，缺一环，结论就站不住。

我的独特判断有三条，可能和主流方法论不太一样。第一，模板数量必须被当作负债管理，而不是资产，任何增长都要付出检索成本和选择成本。第二，字段填写率不能进考核，一旦进考核数据就会失真，正确做法是把它作为观察指标而非衡量指标。第三，模板治理的决策权必须上移到管理层，PMO 只负责出数据和提建议，因为没有决策权的分析不会产生任何实际变更。

如果你正在准备推动这件事，我建议的下一步顺序是这样的：先用两周时间把现有的模板清单、项目实例、字段填写数据导出来，做一次四层指标的快速扫描；然后拿着扫描结果去找分管领导，不是汇报“模板很多”，而是汇报“217 个模板里有 168 个从未被使用，我们每季度为此付出了 X 人天的检索成本”。

管理层要不要推动模板治理，从来不取决于模板体系本身是否合理，而取决于他们能不能看到不治理的具体代价。把代价算清楚，把决策权交上去，这件事才能真正落地。