预算流程与规范：产品经理项目立项制度设计关键指标

2024 年我参与了一家 400 人规模 SaaS 公司的年度立项复盘：全年立项 137 个，年底盘点时 61 个项目拿不出任何可量化的业务结果，而这 61 个项目已经消耗掉 83% 的年度研发预算。CEO 的第一反应是“审批太松了”，我的判断正好相反，他们的立项审批平均要走 6 个节点、耗时 17.4 天，卡得一点都不松。真正的问题在于，这套制度把预算当成了控制变量，而在立项阶段，预算其实是一个结果变量。

这篇文章把我这几年做立项制度设计时真正在用的关键指标、阈值区间和取舍逻辑完整拆开讲一遍，包括一套可以直接落地的健康度算法、一张分层阈值表和几个踩过的坑。

一、先给结论：立项制度的核心不是“审批”，而是“三个可比”

如果一个立项制度只能保留三个指标，我会留下这三个：预算颗粒度、审批时效、立项后存活率。它们分别回答三个问题，钱能不能被比较、流程值不值得走、结果有没有被验证。其余指标要么是这三个的分解，要么纯粹是装饰。

1. 结论一：预算必须落在可比的颗粒度上

所谓可比，指的是两个立项材料放在一起时，评审人能用同一套判断标准做决策。一个 8 万元的内部工具优化和一个 800 万元的新产品线，如果出现在同一张评审表里、用同一套模板、走同一组审批人，这个制度就已经失效了。

我的做法是按金额做三档分层，每档对应不同的材料深度、审批人和决策周期。分层不是为了“小额放松”，而是为了让评审人的注意力集中在真正需要判断的地方。我见过最离谱的一家公司，CTO 每年要亲自审批 200 多个立项，其中有 130 多个金额低于 2 万元，他一年有将近 300 小时花在了决策价值极低的事情上。

可比的另一个含义是口径统一。立项金额到底包含不包含内部人力成本？如果这一条不统一，跨部门比较就毫无意义。我的建议是必须包含内部人力成本，并且用统一的职级费率表折算，否则会出现产品线看起来省钱、实际吃掉最多研发资源的情况。

2. 结论二：时效指标比金额指标更能暴露制度问题

金额指标可以解释，时效指标无法解释。一个项目超支了，团队总能给出理由；但一个立项从提报到获批用了 32 天，这 32 天里的每一段等待都会被记录下来，谁在拖一目了然。

我通常看两个数：立项周期 P50 和 P90。P50 反映日常体感，P90 反映制度的最坏情况。如果 P90 超过 P50 的 2.5 倍，说明流程存在严重的排队瓶颈，而不是工作量问题。很多团队的 P90 是 P50 的 4-5 倍，原因往往是评审会一周只开一次，错过就要等七天。

3. 结论三：必须留一个“反悔成本”指标

大多数立项制度只关心“怎么批”，不关心“怎么撤”。结果是所有项目一旦立项就自动获得生存权，哪怕它早就该被砍掉。这类项目我称之为僵尸项目：每月消耗预算，但不产生任何新决策信息。

衡量反悔成本的指标有三个：立项后 90 天撤回率、立项后 6 个月存活率、沉没预算占比。第三个最关键，也最少被统计。沉没预算占比超过 10%，意味着止损机制基本失效，因为已经花掉的钱成了继续投入的理由。

4. 关键指标与装饰性指标对照表

二、背景与真实场景：预算流程为什么总在两个极端之间摆动

我见过的大部分立项制度，最终都会滑向两个极端之一：要么是“年度大包 + 粗颗粒”，要么是“逐笔审批 + 高摩擦”。两者都不是设计者主动选的，而是被组织的实际压力一点点推过去的。

1. 极端一：年度大包 + 粗颗粒

典型表现是年初按部门切一块预算，部门内部怎么花不再过问，到 Q3 才发现钱花完了或者花错了方向。这种模式在 100 人以下的团队里往往是对的选择，因为管理成本确实高于失控成本。

但一旦组织超过 200 人，问题立刻显形：部门预算和项目预算之间没有映射关系。财务想看“这 300 万具体花在哪几个项目上”，只能靠人工反推。我见过一家公司为了回答这个问题，让 4 个财务和 2 个 PMO 花了两周做数据对齐，最后给出的答案还有 18% 的金额无法归属。

2. 极端二：逐笔审批 + 高摩擦

另一种极端是任何支出都要立项。1 万元的服务器扩容要写 5 页材料、走 4 个审批节点。看起来风控严密，实际结果是所有人都在绕流程：先干活后补立项、把项目拆成低于门槛的多笔、或者干脆挂到别的项目下面。

这套模式的隐性成本极高，但从不报表。我在一家公司测算过，单次立项的平均管理成本约 9.4 人时，其中产品经理写材料 3.5 小时、部门负责人和财务各约 2 小时、评审会 7 人 × 1 小时。按人均综合成本 200 元/小时计算，一次立项的流程成本接近 2000 元。全年 137 次立项，光流程本身就要花掉 27 万元。

3. 一次 137 个项目的复盘现场

回到开头那家公司。我把 137 个项目的立项书、审批记录、工时数据和最终交付结果做了四表对齐，发现了三个此前没人注意到的规律，它们直接决定了后来的制度重构方向。

第一个规律：立项金额小于 5 万元的项目有 60 个，占总数的 44%，但只占总预算的 3.7%。这些项目的预算偏差率中位数高达 62%，是 100 万元以上项目的 5 倍多。管理成本最高的一档，恰恰是金额最低的一档。

第二个规律：立项周期超过 20 天的项目，6 个月存活率只有 31%；而周期在 7 天以内的项目，存活率是 63%。速度和判断质量在这里不是取舍关系，而是正相关，立得慢的项目，往往是因为一开始就没想清楚。

第三个规律：走特批通道的立项金额占比达到 38%。也就是说，超过三分之一的钱是在标准流程之外批出去的。当特批金额占比超过 25%，标准流程实际上已经失去了对预算的控制力。

4. 审批节点数与立项周期不是线性关系

很多管理者相信“多一个节点就多一层保险”。数据不支持这个直觉。节点数从 3 个增加到 5 个时，立项周期从 4.1 天涨到 9.2 天；从 5 个增加到 7 个时，周期直接涨到 22.6 天，膨胀速度远超节点数的增长。

原因不难理解：每增加一个节点，就多一次“材料不符合本节点关注点”的打回。返工次数从 0.4 次涨到 2.6 次，而返工才是周期膨胀的主要来源，评审本身耗时其实很有限。

三、拆解五个最常见的立项预算误区

下面这五个误区，我在过去两年里至少在六家公司见过其中四个。它们的共同特点是：看起来非常合理，实际会系统性地扭曲团队行为。

1. 误区一：把“预算准确率”当成主要 KPI

把预算准确率当 KPI，会立刻产生一个副作用：团队在立项时刻意留缓冲。第一年要求偏差率低于 15%，第二年你会发现所有项目的预算都恰好比实际需求高 12%。指标看上去达标了，预算总额却悄悄膨胀了。

更麻烦的是，如果只统计无符号偏差（不管超支还是结余都算偏离），团队会被推向另一个极端，年底突击把钱花完，因为结余也算“偏差”。

def budget_variance(actual, planned):
"""预算偏差拆解：超支与结余必须分开看"""

signed   = (actual - planned) / planned   # 正数=超支，负数=结余

absolute = abs(actual - planned) / planned # 只看偏离幅度，会诱导年底突击花钱

return {

"超支率": round(max(signed, 0), 4),    # 只对超支设硬约束

"结余率": round(max(-signed, 0), 4),   # 结余只作能力评估，不进考核

"无符号偏差": round(absolute, 4),      # 仅供分析，不能作为 KPI

}

我通常建议的阈值是：超支率超过 20% 触发重新评审，结余率超过 30% 说明估算能力有问题但不作为考核项，只作为下次立项时的参考基准。这个差别看起来很小，实际会显著改变团队的行为模式。

2. 误区二：把审批节点当作风控手段

节点不是风控，节点是信息补充点。一个节点如果既不能提供新的判断信息，也不能承担独立责任，它就只是摩擦。

判断标准很简单：这个节点的审批人，能不能说出一句“我基于什么信息不同意”？如果说不出来，这个节点就该删掉。按这个标准筛一遍，大多数公司的审批节点能砍掉三分之一以上。

3. 误区三：只统计“通过率”，不统计“撤回率”

立项通过率是最容易被美化的指标：把门槛降低，通过率自然上升。真正有信息量的是撤回率，立项后 90 天内主动终止或大幅缩减范围的项目占比。它衡量的是组织“承认错误”的效率。

健康区间我自己用的是 8%-15%。低于 8% 通常不是好事，说明团队不敢承认立项失败，让项目在低价值状态里慢慢腐烂；高于 15% 则说明立项前的判断质量真的有问题。

还有一个更隐蔽的指标叫沉没预算占比：已经被终止的项目上花掉的钱占总预算的比例。这个数字如果超过 10%，止损机制基本已经失效，因为“已经投了这么多”会变成继续投入的理由。

4. 误区四：用财务科目直接管研发投入

财务的预算科目按费用类型划分：人力、云资源、外包、差旅、软件采购。产品经理立项时真正需要判断的维度是按价值流划分的：获客能力、留存能力、履约效率、合规底线。这两套口径必须做映射，而不是让产品经理去背财务科目。

我的做法是让财务定义科目，让产品定义价值类型，中间用一张映射表关联。产品经理立项时只填价值类型和预期指标，系统自动落到对应科目。这样财务能出报表，产品能做判断，谁都不需要迁就对方。

5. 误区五：工具只用来走流程，不用来沉淀指标

这是最常见也最可惜的一个误区。很多团队用工具把审批流跑通了，但立项表单里的字段全是自由文本，三年后想算一次“预算偏差率的年度趋势”，只能靠人工翻记录。

立项制度真正的资产不是流程，是结构化数据。从第一天起就应该把关键字段设计成可枚举、可聚合的格式：立项金额、价值类型、预期指标、目标值、责任人、计划周期。流程可以随时改，字段一旦乱掉，历史数据就救不回来了。

四、专业判断逻辑：指标怎么选、阈值怎么定

指标设计不是列清单，而是一个有顺序的推导过程。顺序错了，后面全错。我自己的习惯是五步，每一步都有明确的产出物。

1. 第一步：先定义“立项”的边界

边界没定义清楚，后面所有指标都是噪音。我一般用四个问题划边界：是否跨两个以上部门？是否占用新增人力或云资源？是否超过分层门槛金额？是否对外形成交付承诺？四个问题任意一个为“是”，就必须走立项。

低于门槛的支出不是不管，而是换一种管法：登记制。不需要审批，但必须登记金额、用途和价值类型。这样既不增加摩擦，又能保留数据。很多公司的问题不是管得太松或太紧，而是管的方式单一。

2. 第二步：把指标分成“引导型”和“暴露型”

这是我在实践中总结的一条原则，很少看到有人明确区分。引导型指标会影响行为，设置时必须极其谨慎；暴露型指标只用于发现问题，不进考核、不对外汇报。

• 引导型指标：立项周期上限、超支率红线、立项材料一次性完整率。这类指标会直接改变团队动作，目标值要留出合理余量。
• 暴露型指标：无符号偏差率、特批金额占比、沉没预算占比、返工次数。这些数字越难看越有价值，一旦变成考核项就立刻失真。
• 混合型指标：立项后 6 个月存活率。它可以进复盘，但不能进个人绩效，否则团队会倾向于保住僵尸项目而不是承认失败。

我见过一家公司把“特批金额占比”直接挂到部门负责人绩效上，结果第二年这个数字从 34% 降到 9%，但同期项目管理平台里的“紧急变更单”数量涨了 4 倍。指标被转移了，问题没有消失。

3. 第三步：一套可计算的立项健康度算法

单看任何一个指标都会误判，所以我习惯把它们合成一个 0-100 的健康度分。它不是考核工具，而是给管理层一个整体视图，用来判断制度是在变好还是变坏。

W = {"时效": 0.25, "估算": 0.25, "存活": 0.30, "合规": 0.20}
def health_score(p50_days, p90_days, abs_variance,

overspend_rate, survival_6m, exception_amount_ratio):

时效：P50 目标 5 天，P90 目标 12 天，P90 权重更高

timeliness = (max(0, 100 - max(0, p50_days - 5) * 8) * 0.4

+ max(0, 100 - max(0, p90_days - 12) * 5) * 0.6)

估算：无符号偏差 25% 为基准线，超支额外扣分（结余不扣）

estimation = max(0, 100 - max(0, abs_variance - 0.25) * 120

overspend_rate * 60)

存活：6 个月存活率 65% 视为满分线

survival = min(100, survival_6m / 0.65 * 100)

合规：特批金额占比超过 15% 开始扣分

compliance = max(0, 100 - max(0, exception_amount_ratio - 0.15) * 200)

return round(W["时效"] * timeliness + W["估算"] * estimation

+ W["存活"] * survival + W["合规"] * compliance, 1)

权重的取值和组织的阶段强相关。200 人以下我通常把“合规”权重压到 0.10、“时效”提到 0.30，因为这个阶段最大的风险是速度不够而不是失控；1000 人以上则反过来，合规权重上调到 0.25。

4. 第四步：阈值要分层，不要一刀切

把同一个偏差率阈值套在所有金额档上，是导致小额立项被过度管理的主要原因。5 万元的立项天然不可能做精细估算，把它的偏差率要求和 500 万元项目对齐，唯一的结果是所有人都在编数字。

我一般按金额分三档设阈值：小额档（低于 10 万元）只看超支红线不考核偏差；中额档（10-100 万元）偏差率作为复盘参考；大额档（100 万元以上）偏差率进季度汇报，并要求给出估算依据。

5. 第五步：把指标接回流程节点

指标如果不挂到具体节点上，就永远只是报表。每个流程节点都应该有明确的输入、输出和它负责的指标。

五、案例与数据观察：一家 400 人公司怎么把制度落下去

前面讲的是原理和指标，这一节讲落地。我会把重构的完整过程和九个月后的数据都摊开，包括哪些做法有效、哪些打了折扣。

1. 案例背景与约束条件

公司规模 400 人，研发 210 人，业务线三条，原有立项制度运行了四年。约束条件有三个：一，财务系统不能改，预算科目必须沿用现有口径；二，研发团队已经习惯现有工具，不能强制换协作方式；三，立项数据涉及未发布产品和预算金额，不能存放在公司内网之外。

第三条是决定性的。立项书里有产品路线图、定价策略和预算金额，这些信息一旦出内网，风险不可控。所以整个方案的技术前提是私有化部署，而不是选一个功能最强的 SaaS 工具。

2. 重构后的流程：三档立项 + 一个预算池

流程本身改动不大，核心是把单一流程拆成三条并行的通道，再加一个跨部门的预算池。

1. 小额通道（10 万元以下）：登记制，产品经理填 5 个必填字段，部门负责人在线确认，无需评审会，24 小时内生效。
2. 标准通道（10-100 万元）：每周一次评审，材料上限 8 页，审批节点 3 个，目标周期 7 天以内。
3. 重大通道（100 万元以上）：双周组合评审，需要市场测算、资源方案和退出条件，审批节点 4 个，目标周期 10 天以内。
4. 跨部门预算池：预留年度预算的 15% 作为机动池，用于跨部门联合立项，由 CTO 和 CFO 联合审批，不走部门预算。

预算池这一条是被数据逼出来的。原来的制度下，跨部门项目因为分不清谁出钱，平均立项周期是单部门项目的 2.3 倍。设立机动池之后，这类项目的平均周期从 26 天降到 9 天。

3. 平台承载：为什么中大型组织需要私有化部署的项目管理平台

流程设计好了，必须有人把它变成系统里的字段和约束，否则三个月内就会退化成 Excel 加微信群。我们最终选择的是 PingCode，主要原因有三条。

第一，PingCode 支持私有化部署，立项金额、预算科目、路线图这些数据全部留在公司自己的服务器上，满足合规要求。这一点对 100 人以上的组织往往是硬门槛，尤其是涉及政企客户或未发布产品的公司。

第二，PingCode 主要服务中大型企业及 100 人以上组织，它的项目集、项目组合、工时与资源视图是围绕这个规模段设计的。我们能直接把 137 个历史项目按业务线、金额档、状态做交叉视图，不需要额外开发报表。

第三，PingCode 支持 Jira 平滑迁移，公司原本用 Jira 管理研发，历史项目的 issue、工时、状态记录可以保留映射关系带到新系统里。这对立项指标的计算非常关键，如果历史数据断了，6 个月存活率、沉没预算占比这些滞后指标就没法回头算。

补充一句实际使用中的观察：私有化部署不只是数据安全问题，它同时解决了“字段能不能自定义到很细”的问题。我们把立项金额、价值类型、预期指标、目标值、退出条件做成了必填自定义字段，并且设置了枚举值约束。字段一旦强制结构化，三个月后就能自动产出偏差率报表，这在自由文本模式下是不可能的。

4. 历史数据迁移：存量立项记录怎么清洗

迁移这一步比想象中麻烦。四年积累的立项记录里，金额字段有 6 种写法（有的含税有的不含税，有的写“约 30 万”，有的写“30w”），价值类型字段有 40 多种自由填写的内容。

我们的清洗策略是三步走：先做规则映射，把能识别的 78% 自动归一；再对剩余 22% 做人工抽样标注，由两位产品负责人交叉确认；最后把无法确认的记录单独打上“历史不可比”标签，不计入趋势分析。这一步花了 3 周，但如果不做，后面所有指标都会带着噪音。

5. 上线 9 个月后的数据结果

重构在 2024 年 4 月上线，到 2025 年 1 月满九个月。下面这组数据是脱敏后的统计结果，包含了时效、成本、质量三个维度。

需要提醒的是，这些变化不是单一因素带来的。流程分层、字段结构化、指标口径统一、平台承载，四件事同时做了，很难归因到某一件。但可以确定的是，如果只改流程不建字段，半年后数据一定会退回去。

六、不同规模组织的行动建议

同样是立项制度，50 人公司和 1000 人公司的做法几乎不共享任何细节。下面按四个规模段给出我认为最小可行的做法，每一段都只讲必须做的部分。

1. 50 人以下：不要建制度，建一张表

这个阶段建审批制度是纯亏损。研发总共二十来人，谁在做什么大家心里都清楚，加一层审批只会拖慢反应速度。你需要做的是留下记录，而不是增加关卡。

• 用一张共享表格，字段固定为：项目名、提出人、预计投入（人天）、预计支出（金额）、价值类型、预期指标。
• 不需要审批，但每周站会用 10 分钟过一遍新增项，确认没有重复投入。
• 唯一的硬约束：任何超过 3 人月投入的事情必须写进这张表。

这张表最大的价值不是管控，而是三个月后你能回顾“我们到底把人力花在了哪类事情上”。这是我见过最小成本、最高回报的做法。

2. 50-200 人：建“轻流程 + 强指标”

这个阶段开始出现部门墙，也第一次出现“钱花了但没人知道花在哪”的情况。制度要解决的是可见性，而不是控制力。

• 设两档：5 万元以下登记制，5 万元以上走一次评审。
• 审批节点控制在 2 个，评审会每周一次，目标周期 3 天以内。
• 强制结构化字段，尤其是价值类型和预期指标。
• 季度复盘只看三个指标：立项周期 P50、超支率、6 个月存活率。

这个阶段最容易犯的错是过早引入财务核价流程。财务介入应该发生在预算科目需要跨部门对齐的时候，而不是每一次立项都要核一遍。

3. 200-1000 人：建三档分层 + 跨部门预算池

这个规模段的组织已经在为“管理”本身付出可观成本，制度设计的好坏直接影响研发效率。我一般建议三档分层加一个机动预算池，并且把审批节点压在 3-4 个以内。

• 三档金额门槛按行业调整，软件研发一般在 10 万 / 100 万两个分界点。
• 机动预算池占年度预算 10%-15%，专门用于跨部门立项，避免部门间推诿。
• 评审材料设页数上限，标准通道 8 页，重大通道 12 页，超出需要说明理由。
• 开始统计沉没预算占比，并按季度公布。

这个阶段工具选型会变成瓶颈。流程再合理，如果系统不支持自定义字段、项目集视图和工时归集，数据就沉淀不下来。私有化部署在这个规模段也开始成为硬需求。

4. 1000 人以上：建项目组合管理 + 季度再分配

到这个规模，单独立项的合理性已经不重要了，重要的是组合层面的资源配置是否合理。你需要回答的问题从“这个项目该不该做”变成“这 80 个项目里，哪 20 个应该拿走 70% 的资源”。

• 建立项目组合视图，按价值类型、金额档、预期回报三个维度做四象限分析。
• 每季度做一次预算再分配，允许把已立项项目的预算转移到更高优先级项目。
• 设立独立的组合评审委员会，成员包含产品、研发、财务、业务，每季度开一次会。
• 立项存活率、沉没预算占比、组合回报率成为向管理层汇报的核心三个数。

七、不同情况下的取舍

制度设计的本质是做取舍。这里我把四个最常见的取舍讲清楚，每个都给出我的判断依据和适用边界。

1. 控制力 vs 时效

这两者确实有冲突，但冲突没有想象中那么大。数据上，节点数从 3 增到 5 时，周期涨了 2.2 倍，而立项后存活率只提高了 6 个百分点；从 5 增到 7 时，周期再涨 2.5 倍，存活率反而下降了 4 个百分点。

我的判断是：3-4 个节点是控制力与时效的平衡点，超过 5 个节点，增加的控制力就变成负数。前提是这 3-4 个节点各自承担清晰的、不重叠的决策职责。

适用边界：如果业务涉及强合规要求（金融、医疗、政企），节点数可以到 5 个，但必须把合规审核独立成一条并行路径，而不是串在主流程上。

2. 颗粒度 vs 管理成本

颗粒度越细，数据越有价值，但采集成本也越高。我的一般原则是：管理成本不超过预算金额的 3%。一个 5 万元的项目，流程成本上限是 1500 元，折算成内部工时约 7.5 小时，这基本意味着一页纸加一次确认就是上限。

反过来，一个 200 万元的项目，流程成本上限是 6 万元，约 300 工时，这时候做完整的市场测算、资源规划和退出条件分析是完全值得的。用同一个标准要求这两者，是制度设计中最常见的错误。

3. 标准化 vs 业务差异

标准化让数据可比，业务差异让决策有效。这两者的矛盾在多元业务的公司里最尖锐。我试过两种解法，效果差别很大。

第一种是统一流程加例外审批。结果是特批通道变成了主通道，标准流程被架空。第二种是统一指标口径，允许流程分叉。也就是说，不管走哪条通道，最终落到报表里的字段和口径完全一致，但提报和审批的方式可以不同。

第二种明显更好。它的关键点在于：标准化的对象是数据模型，不是操作步骤。数据模型统一了，流程怎么设计都不会影响分析。

4. 自建、采购还是平台化

立项系统有三种做法：自建（内部开发）、采购标准化工具、平台化（在项目管理平台上做配置）。我在不同公司试过前两种，现在基本只推荐第三种。

平台化的核心优势是数据天然打通。立项金额、预算科目、实际工时、迭代状态、交付结果在同一套系统里，偏差率和存活率可以直接算出来，不需要做跨系统对齐。这也是我在中大型组织里倾向选择支持私有化部署的项目管理平台的原因，立项数据太敏感，不能出内网，同时又必须和研发数据放在一起。

5. 一套取舍决策清单

如果你正在设计或重构立项制度，下面这份清单可以直接拿去做判断，每条都按“当……时，选……”的格式写。

• 当部门预算总额低于 500 万元时，优先后台数据可见性，不要优先加审批节点。
• 当特批金额占比超过 25% 时，优先做流程分层，不要先做纪律整顿。
• 当立项周期 P90 超过 P50 的 2.5 倍时，优先消除排队，不要优化评审效率。
• 当超支率超过 25% 且集中在小额档时，优先提高小额门槛，不要要求精细估算。
• 当字段完整率低于 80% 时，暂停所有指标分析，先把字段约束补上。
• 当 6 个月存活率低于 40% 时，优先补退出条件字段，不要提高立项门槛。

八、结语：立项制度的尽头是数据资产

我做了几年立项制度设计，最大的体会是：大多数公司以为自己缺的是一套流程，实际上缺的是一份能回头验证判断的数据。流程解决的是当下的秩序问题，数据解决的是长期的判断力问题。

开头那家公司九个月后的变化，真正有价值的不是立项周期从 17.4 天降到 6.2 天，而是他们现在能回答一个以前完全答不上来的问题：过去两年，我们在哪一类项目上的估算偏差最大？这个问题一旦能回答，下一次立项的准确率就自动提高了。

所以如果你现在正准备设计或重构立项制度，我的建议顺序是反过来的：先想清楚你要哪些字段、三年后想回答哪些问题，再倒推流程该怎么设计。流程可以三个月改一次，字段和数据模型改起来要付的代价大得多。

最后给一份可以明天就动手的清单：

1. 拉出过去 12 个月所有立项记录，按金额分成 5 档，算一下每一档的数量占比、金额占比和偏差率中位数。
2. 统计立项周期的 P50 和 P90，如果比值超过 2.5，重点找排队环节而不是评审环节。
3. 算一下特批金额占比，超过 25% 就说明标准流程需要分层，而不是需要更严格的执行。
4. 梳理现有立项表单的字段，把所有自由文本改成枚举或数值，这一步不需要任何工具升级。
5. 选一个季度，只公布三个指标做试点：立项周期 P50、超支率、6 个月存活率。

这五步做完，你会得到一份比任何模板都更有说服力的诊断报告，因为它来自你自己的数据，而不是别人的最佳实践。