立项流程与规范：项目经理项目立项效率提升关键指标

2021 年我帮一家 300 人规模的制造企业梳理立项流程，做完数据统计之后发现了一个让我自己都不太舒服的数字：这家公司从”立项申请提交”到”立项号下发”，平均耗时 27.4 个工作日，而立项通过率是 96%。

换句话说，27 天里几乎没有人真正否决过任何一个项目。流程很长，但它不是在控制风险，只是在排队盖章。第二年复盘时，这家公司有 6 个立项项目在启动后 60 天内被推翻或大幅改范围，返工带来的直接人力浪费超过 400 人天。

这件事彻底改变了我对”立项效率”的理解。立项效率的核心不是”批得快”，而是”单位决策成本换来的决策质量”。一个 27 天、96% 通过率的流程，看起来严谨，实际上是把风险从立项阶段推迟到了执行阶段，代价更高。

这篇文章我会把立项流程与规范这件事拆开讲：哪些指标是真的该盯的，哪些指标看起来专业其实是自欺欺人，不同规模的组织该走哪条路，以及我自己踩过的坑。所有数据都是我在实际流程改造中记录的样本，口径我会讲清楚，方便你判断能不能套用到自己的组织。

一、先给结论：立项效率的三个正向指标和一个负向指标

在讲方法和背景之前，我先把结论摆出来。如果你只想知道”项目经理应该盯哪几个指标”，看完这一节就够了；如果你想理解为什么是这几个，后面的章节再展开。

1. 立项效率不等于立项速度

我见过太多团队把”缩短立项周期”当成唯一目标，结果是把评审会从两小时压到四十分钟，把材料从 30 页压到 5 页，周期确实降了，但立项后的变更率翻了一倍。

这不是效率提升，这是风险转移。立项阶段省下来的每一个小时，都会在执行阶段以三到五倍的代价还回去。

我的判断是：立项效率是一个”多指标组合”的概念，单独追任何一个指标，都会导致系统性失衡。就像只看体重减肥，最后减掉的是肌肉和水。

2. 三个正向指标：前置时间、一次通过率、信息完备度

我给这三个指标的定义，和大多数模板里写的略有不同，差别主要在口径。

• 立项前置时间（Lead Time）：从”立项材料被判定为齐全”到”立项决议正式生效”的日历时间。注意起点不是”想法产生”，终点不是”会议开完”。
• 一次通过率（First Pass Rate）：首次提交即获得通过（含条件通过）的立项占比。分母必须包含主动撤回的申请，否则数据会被人为美化。
• 决策信息完备度（Decision Completeness）：必填决策字段的实际提供比例，按权重加权。权重建议向财务假设、验收口径、资源来源三项倾斜。

为什么起点要定在”材料齐全”？因为如果起点定在”想法产生”，你测到的主要是发起人的拖延程度，而不是流程效率。这个口径问题我在三家公司都遇到过，改口径之后，立项周期数据立刻从”不可解释”变成”可优化”。

3. 一个负向指标：立项后 30 天重大变更率

这是我个人最看重、但在公开资料里最少被提到的指标。

立项后 30 天重大变更率 = 决议生效后 30 天内，发生预算、范围、里程碑、责任人、验收标准中任意一项重大变更的立项数 ÷ 同期立项总数。

这个指标的意义在于，它是立项质量的事后验证。立项流程再漂亮，如果 30 天内三分之一的项目都被推翻重来，说明这个流程只是在生产形式合规，没有在生产决策。

4. 指标之间的张力：为什么单独追任何一个都会翻车

这四个指标之间存在真实的、无法消除的张力，理解这一点比记住指标本身更重要。

压低前置时间，通常会让信息完备度下降，进而推高 30 天变更率。抬高信息完备度要求，会拉长前置时间，并且可能降低一次通过率（因为要求高了，暴露的问题多了）。

所以指标管理的关键不是”每个都做到最好”，而是先确定你当前阶段的约束条件，再决定牺牲哪一个。预算收紧期优先保变更率，市场窗口期优先保前置时间。这个取舍逻辑我放在第七节展开。

二、背景与真实场景：我在三家公司看到的立项现场

抽象讲指标容易空。我把三家公司真实的立项现场写出来，你会发现问题的形态高度相似，只是量级不同。

1. 场景一：11 个审批节点的”橡皮章流程”

第一家是一家 800 人的软件公司，立项审批链路上有 11 个节点，包括部门负责人、产品负责人、架构组、测试负责人、财务、法务、采购、运维、安全、分管副总、总经理办公室。

我调了三个月的审批日志，发现一个规律：流转耗时排前三位的是三个”纯确认型”节点，加起来占全流程耗时的 47%，而这三个节点在半年内没有提出过任何一次实质性修改意见。

这就是典型的橡皮章流程。节点多不代表把关严，只代表责任被稀释了，每个节点都觉得”前面有人看过了”。

2. 场景二：300 人公司的 27 天立项周期，卡在排期不在评审

第二家就是我开头提到的那家制造企业。我们把它完整的立项链路拆开测了一遍，得到一组很有意思的数据。

材料准备 4.8 个工作日，部门初审 2.1 天，财务核价 3.4 天，技术评审 2.6 天，决策会排期等待 5.2 天，决议签发 1.1 天。实际处理时间合起来是 14 天，但加上会前的材料往返、人员出差、领导排期，日历时间被拉到 27 天以上。

关键发现是：真正可以压缩的不是评审本身，而是等待。评审会开两小时还是三小时，对整体周期影响不到 5%；但决策会从”每月一次”改成”每周三固定一场”，周期直接砍掉近一周。

3. 场景三：立项在 OA、执行在研发平台的两张皮

第三家是一家 1200 人的企业，立项审批走 OA 系统，研发执行走独立的研发管理平台，两边互不打通。

结果是一个立项项目在两套系统里有两套信息。OA 里的预算是 180 万，研发平台里的项目工时折算下来是 260 万，中间差了 80 万，但没有人知道该以哪个为准。

更麻烦的是复盘。想做”立项估算准确度”分析时，得人工把两边的表导出、按项目名模糊匹配，一次复盘三个人做四天。这种”系统两张皮”是立项效率最隐蔽的杀手，因为它不体现在任何单个环节的耗时上，而是体现在整体不可优化。

4. 为什么这两年立项效率突然变成硬问题

我的观察是三个因素叠加。

第一是组织规模跨过临界点。100 人以下时，立项靠口头沟通和微信群就能闭环；超过 300 人后，信息传递损耗呈非线性上升，原来不需要的流程开始变得必要。

第二是预算环境变化。预算宽松时，立项审批的重点是”选哪个”；预算收紧时，重点变成”要不要做”，后者的决策难度和执行成本都高得多。

第三是合规要求细化。数据安全、供应商准入、知识产权归属这些维度，在五年前很多公司的立项模板里根本没有字段，现在必须有，而且要求留痕。

这三个因素叠加的结果是：立项流程必须从”人治的默契”升级为”可度量、可分级、可追溯的规范”，但升级方式不能是简单加节点。

三、拆解误区：立项流程里最常见的六个认知陷阱

下面这六个误区，是我在流程诊断中反复遇到的。它们的共同特点是：看起来非常符合直觉，甚至看起来很专业，但实际效果与预期相反。

1. 误区一：把审批节点数量当成风险控制能力

“多加一道审核，风险就小一点”，这个逻辑只在审核人拥有独立信息且愿意承担否决成本时成立。

现实中更常见的是：节点越多，每个节点投入的注意力越少。我统计过一个 11 节点流程，单个节点的平均处理时长是 8 分钟，其中 6 分钟在确认”前面的人签了没有”。

真正的风险控制来自”关键维度是否有独立验证”，而不是”有多少人签了字”。三个高质量的验证点（成本、技术可行性、合规）比十一个确认点有效得多。

2. 误区二：把立项文档字数当成论证深度

我见过一份 68 页的立项报告，其中 41 页是从上一版复制粘贴的市场分析，真正描述”这个项目为什么现在做、做不成怎么办”的篇幅不到 3 页。

评委看到 68 页，本能反应是”这份材料很用心”，然后跳过细节只看结论。页数在这里起的作用是反向的：它降低了评审的信息密度，而不是提高了。

我的做法是把立项材料按”决策必需”和”备查”拆开。决策必需的部分控制在 2 页以内，用结构化字段填充；备查部分放进附件，不强制评审前阅读。

3. 误区三：一套模板套所有项目类型

一个 3 万元的内部工具采购和一个 800 万元的新产线建设，用同一份立项模板，是很多公司的默认状态。

后果有两层。对小微项目，模板太重，发起人要么放弃立项走报销绕过流程，要么随便填一份糊弄过去，两种结果都让流程失效。对大型项目，模板太浅，关键的产能测算、供应链风险、退出机制都没有字段。

正确做法不是”优化模板”，而是先把项目分类，再给每类配一套不同的材料清单和评审深度。这是我第四节要讲的三档通道的基础。

4. 误区四：追求 90% 以上的立项通过率

立项通过率高，通常被解读为”我们的项目质量好”。但立项和投资不一样，投资标的可以筛选，立项项目是自己提的。

一个立项通过率长期在 95% 以上的组织，更可能的情况是：不该提的项目压根没被提上来过，或者提上来只是为了走个形式。真正起到筛选作用的前置评估，已经被跳过或者被绕过了。

我的经验区间是：备案制通道通过率 90% 以上正常，评审制在 70% 到 85% 之间比较健康，门禁制低于 60% 说明筛选在真正起作用，高于 85% 就要警惕是不是评审标准过松。

5. 误区五：立项系统与执行系统分离

这一条我在第二节场景三里讲过，这里补充它的长期代价。

当立项和执行分属两套系统时，最先丧失的能力是”估算校准”。你想知道去年同类项目的实际成本比立项估算高多少，正常情况下这是一个查询，但分离状态下它变成一个需要三天的数据分析任务。

失去这个能力之后，立项评审就只能靠经验和感觉，而经验在人员流动率高的组织里衰减很快。项目立项效率的天花板，本质上是由历史数据可复用程度决定的。

6. 误区六：只统计立项周期，不追踪立项质量

这是最常见的管理缺口。很多公司每月出一张”平均立项周期”报表，但没有任何一张报表统计”立项后变更”。

结果是流程优化变成一味求快，直到某天业务方集体抱怨”项目老是做一半改需求”，才发现问题出在立项。而这个时候，损失已经发生了。

四、专业判断逻辑：立项效率的四层模型与三档通道

讲完问题，讲我的方法。这套方法是我在六次流程改造中逐步磨出来的，目前还在用，也还在改。

1. 四层模型：合规层、决策层、资源层、追踪层

我的核心判断是：绝大多数立项流程的混乱，来源于把四个性质完全不同的目标塞进同一个流程。

这四层是：

• 合规层：这个项目能不能立。判断依据是外部规则和内部红线，比如数据合规、供应商准入、资金使用范围。这一层是硬性的，不能打折。
• 决策层：这个项目该不该立。判断依据是收益假设是否成立、有没有更优替代方案、不做会怎样。这一层需要真正的判断力，最贵也最容易走过场。
• 资源层：拿什么立。判断依据是人力、预算、设备、外部依赖的具体来源和时间。这一层最容易写成”内部协调”，也最容易在执行时爆雷。
• 追踪层：立了之后怎么验证。判断依据是验收口径和预设终止条件。这一层被跳过的比例最高，代价也最大。

四层分开之后，你会发现很多流程问题自然消失：合规层可以做成清单式自检，不需要开会；决策层才需要把关键人聚在一起；资源层适合前置到提交之前；追踪层是立项落地后的事，不该占用评审时间。

2. 三档通道：备案制、评审制、门禁制

分类是分级的前提。我给项目分三档通道，判断标准是投入规模、合规强度、跨部门程度、技术新颖度四个维度。

备案制适用于投入小、影响面窄、可逆的项目。提交即生效，事后抽查。评审制适用于中等投入或跨部门协同的项目，一次评审会决定。门禁制适用于高投入、强合规、不可逆的项目，需要多维度独立验证。

关键在于：通道一旦确定，材料清单、评审人、决策方式和周期目标全部随之不同，而不是”所有项目都交同一份材料，只是评审人多少不一样”。

3. 通道判定的阈值设计

下面这张表是我在一家中型制造企业落地的阈值方案，你可以参考结构，具体数字一定要按自己组织的实际情况调整。

注意门槛数字需要定期校准。我建议每半年回看一次通道分布，如果某个通道的项目数量占比超过 70%，说明阈值设偏了，通道已经失去区分度。

4. 通道判定的自动化规则

把判定逻辑写成规则，可以减少大量”这个该走哪个通道”的沟通成本。下面这段是我用过的一个简化版本，用配置化的伪代码表达。

def route_channel(budget_capex_wan, compliance_flag, cross_dept_count, novelty):
budget_capex_wan: 资本性投入，单位万元

compliance_flag: high / medium / low

cross_dept_count: 涉及部门数量

novelty: high / low（是否有可复用的先例方案）

if compliance_flag == "high" or budget_capex_wan >= 200:

return "gate"      # 门禁制

if budget_capex_wan >= 20 or cross_dept_count >= 3 or novelty == "high":

return "review"    # 评审制

return "record"        # 备案制

规则化之后有个额外好处：发起人在提交前就知道自己要走哪条路、要准备什么，不用先问一遍再返工一次。这是我们一次通过率从 58% 提到 79% 的主要来源之一。

5. 立项信息字段的最小集

字段设计是立项规范里最容易被忽视、但影响最直接的部分。我的原则是：只保留能改变决策结果的字段，其余全部删掉。

下面这套 schema 是我在实际项目里用过、并反复精简后的版本，可以直接作为起点。

project_intake:
id: INTAKE-2024-0731

title: 华北仓配一体化系统升级

tier: B # A=战略 / B=部门 / C=小组

channel: review # record=备案 / review=评审 / gate=门禁

owner: 张某某 # 对结果负责的人，不是发起人

sponsor: 供应链负责人 # 承担资源的人

budget:

capex: 186.0 # 万元

opex_annual: 42.5 # 万元/年

basis: 见附件B-单价与数量推导

headcount:

internal_fte: 4.5

vendor_fte: 2.0

confirmed_with: 研发负责人 / 2024-07-28

outcome:

metric: 单均履约成本

baseline: 12.8 # 元/单

target: 10.9

measure_window: 上线后90天

kill_criteria:

若第 1 阶段试点单均成本未降至 12.0 元，终止

若外部接口方在 60 天内未完成联调，降级为局部方案

evidence:

similar_case: PRJ-2022-0119

actual_vs_plan_deviation: +38%

decision:

gate_date: 2024-08-06

approvers: [finance, architecture, supply_chain]

这里面有两个字段我想特别说明。第一个是 owner，我坚持写”对结果负责的人”，而不是”发起人”。很多立项单的发起人是提需求的人，但真正要为交付负责的往往是另一个人，这个错位会导致立项之后没人认账。

第二个是 kill_criteria，也就是预设终止条件。这是我认为最被低估的立项字段。绝大多数立项模板只问”做什么、要多少”，从来不问”什么情况下停”。结果是项目一旦启动就停不下来，沉没成本不断累积。

预设终止条件还有一个隐性收益：它强迫发起人在立项阶段就想清楚”失败的信号是什么”，这本身就是对项目假设的一次压力测试。

五、案例与数据观察：一次 800 人组织的立项流程改造

讲一个我完整参与过的案例，包括做对了什么和踩了什么坑。这家企业 800 人左右，研发与交付人员占比超过一半，年度立项数量在 260 个上下，属于典型的中大型组织。

1. 改造前的状态

改造前的状态可以概括为”三高三低”：立项周期高、返工率高、决策成本高；一次通过率低、信息完备度低、立项后复盘率低。

具体数字是：立项前置时间 14.2 个工作日，一次通过率 58%，立项返工率 42%，单次决策平均消耗 22.5 人时，立项到启动间隔 9.3 天，立项后 30 天重大变更率 33%。

另一个隐性问题是系统割裂。立项审批在一套通用审批工具里，研发项目在研发管理平台上，两边靠人工对齐。迁移前他们做一次同类项目的估算校准分析，需要三个人做四天。

2. 我们做的三件事

改造动作看起来不多，但每一项都需要协调成本。

1. 建立三档通道并设定阈值。把 260 个历史立项按新规则重新分类，结果发现原本走完整审批的项目里，有 63% 符合备案制或简化评审制的条件，属于典型的过度审批。
2. 把立项模板从一份 42 页的文档改为一套结构化字段。决策必需字段 18 个，备查附件不限，但评审前不强制阅读。
3. 把立项与研发执行合并到同一平台。这家企业原本使用 Jira 管理研发流程，改造时选择了 PingCode 作为统一平台，主要考虑三点：一是支持私有化部署，符合他们对代码与项目数据不出内网的要求；二是提供从 Jira 平滑迁移的能力，历史项目数据可以保留并用于估算校准；三是作为国产替代方案，在合规审计上更容易说明数据流向。

第三条我想展开说一下，因为它直接决定了立项效率的天花板。

立项评审最需要的信息是”我们以前做类似的事，实际花了多少、超了多少”。这个信息如果不存在，或者需要人工提取，评审就只能靠感觉。把立项字段和历史项目数据放在同一个平台里之后，发起人填写投入规模时，系统可以直接带出同类项目的历史偏差区间。

在这个案例中，一旦引入历史偏差提示，财务核价环节的平均耗时从 3.4 个工作日降到了 1.6 个工作日。原因很简单：原来财务需要自己去翻记录、找参照，现在参照就在表单里。

3. 数据变化

改造后运行六个月，我把关键指标记录如下。需要说明的是，这是单组织的样本，不是行业基准，请结合自己组织的情况判断。

4. 我在这个案例里踩的坑

第 4 个月的时候，我们为了展示改造成果，把备案制的阈值上调了一次，让更多项目进入快通道。当月立项前置时间降到了 3.9 个工作日，是六个月里的最低值。

但第 5 个月的立项后 30 天变更率反弹到了 23%，比第 3 个月的 19% 还高。复盘发现，有些本来需要跨部门确认的项目被归进了备案制，因为发起人填写的部门数不准确，没人核对。

我们在第 5 个月做了两件事：一是把阈值回调到原值并增加”跨部门数量需由相关部门确认”的必填校验；二是把变更率纳入通道健康度的月度看板。第 6 个月周期回到 4.6 个工作日，变更率降到 12%，是六个月里的最低值。

这件事让我对”追求最短周期”这个目标彻底祛魅了。周期可以被人为压到任意短，但变更率会立刻告诉你这个压缩是否真实。

5. 为什么选择一体化平台而不是继续用审批工具

这个决策当时内部争论了两个月，我把判断逻辑列出来供参考。

• 审批工具解决的是”谁签了字”，一体化平台解决的是”这个决定基于什么信息”。前者是流程合规问题，后者是决策质量问题，立项效率的核心矛盾在后者。
• 历史数据复用能力。审批工具里的数据是流程数据，很难直接用于成本估算校准；研发管理平台里的数据是执行数据，天然可以用于校准。
• 迁移成本与数据保留。中大型组织通常已有大量存量项目，PingCode 提供从 Jira 平滑迁移的能力，历史项目、字段映射、人员关系可以保留，这对依赖历史数据做估算校准的场景很关键。
• 部署与合规约束。部分行业要求项目与代码数据不出内网，私有化部署是硬性条件，这一点在选型阶段就要确认，不能等到上线前才发现。

需要说明的是，一体化不是所有组织的正确答案。如果你的立项和执行本来就简单，团队在 50 人以下，一个轻量表单加一个群就够用，此时上平台反而增加维护成本。一体化平台的价值，是在组织规模跨过 100 人、立项数量超过每月 10 个、且需要跨部门协同之后才开始显现的。

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

方法讲完了，接下来按组织情况给具体动作。我把建议分成四类，你可以直接对照自己的组织。

1. 100 人以下的组织：先别做流程

这个规模下，立项流程的最大风险是”过度设计”。我见过 40 人的团队做了一套 7 节点的立项审批，结果所有人都在绕开它走报销。

建议只做三件事：把预算审批阈值写清楚（比如 5 万以下部门负责人定，5 万以上创始团队定）；要求每份立项写清楚验收口径；每季度花一小时回看”哪些项目做到一半变了方向”。

这个阶段不需要系统，不需要模板库，也不需要指标看板。需要的是把”验收口径”和”预算权限”这两件事说清楚。

2. 100 到 500 人的组织：建立双通道 + 一个指标

这是我最建议投入精力的阶段，因为流程债务开始产生，但还没到积重难返的程度。

建议是建立双通道（备案制 + 评审制），暂不设门禁制，大额项目直接进评审制并加一位独立成本验证人。指标上只盯两个：立项前置时间和立项后 30 天重大变更率。

工具上建议把立项与执行放到同一平台，或者至少保证两边有唯一项目编号可以关联。这一步做了，后面的估算校准才有基础。

3. 500 人以上或多事业部组织：三通道 + 通道健康度看板

这个规模下，最大的问题通常不是流程本身，而是流程在不同事业部的执行差异。

建议建立三档通道，并且按事业部维度出通道健康度看板。看板至少包含四项：各通道立项数量占比、各通道一次通过率、各通道前置时间中位数、各通道 30 天变更率。

如果某个事业部的备案制占比长期超过 70%，大概率不是他们的项目都简单，而是阈值被绕过了。这是需要重点核查的信号。

4. 强监管行业：合规层前置，但不要塞进决策会

金融、医疗、涉及数据安全的行业，合规层的硬性要求多，这是客观约束，不能为了提速去削减。

我的建议是把合规层做成清单式自检 + 系统校验，前置到提交之前。数据流向、供应商准入、知识产权归属这些字段，做成必填 + 自动校验，不通过就不允许提交。

这样做的好处是：合规验证从”评审会上的讨论议题”变成”提交前的技术校验”，既没有降低标准，也不占用会议时间。在强监管场景下，这是我认为唯一可行的提速方式。

七、不同情况下的取舍

最后一节讲取舍。立项效率提升本质上是一系列取舍的结果，没有”全都要”的方案。我把最常见的四组取舍列出来，并给出我的判断依据。

1. 速度 vs 完备：什么时候该牺牲完备

我的判断依据是可逆性，不是金额。

可逆的项目，比如可以随时停掉的工具试用、可以退回的供应商试点，应该优先速度，材料从简，事后补验证。不可逆的项目，比如产线改造、组织架构调整、独占性合同，必须优先完备，周期长是合理成本。

很多组织的错误是用金额做唯一标准。但一个 50 万的不可逆投入，风险远大于一个 200 万的可逆投入。我在阈值设计里一直坚持把”不可逆”单独列为一个判定条件，原因就在这里。

2. 标准化 vs 灵活性：标准该定到哪一层

我的建议是：标准定在字段层，灵活留给内容层。

也就是说，”必须回答验收口径”这件事是标准化的、强制的；但”验收口径具体写什么”完全开放。很多流程之所以被抱怨僵化，是因为它管了内容，却漏掉了字段。

举个具体例子。有的公司要求立项必须写”至少三个备选方案”，这就是在管内容，结果是大家为了凑数编两个凑数的方案。而如果要求的是”必须回答为什么选这个方案而不是另一个”，这就是在管字段，内容由发起人自己决定。

3. 集中审批 vs 分级授权：授权的边界在哪里

授权不是放手。我的做法是：授权决策权，但保留数据和复核权。

具体来说，备案制项目由部门负责人自行决定，但立项信息必须进入统一平台，且每月被抽样复核。复核发现问题的，按比例收回该部门的备案额度。

这个机制的好处是，它给了部门真实的自主权，同时保留了纠偏能力。我在两家公司用过这个机制，效果比”事后审计”好，因为额度收回是即时生效的，而不是几个月后才出报告。

4. 一次重构 vs 渐进迭代：改造节奏怎么定

我的经验是：规则可以一次改完，执行必须渐进。

因为规则改动写在纸上成本很低，但所有人的习惯改过来需要时间。我在一次改造中试过同时上线三档通道、新模板、新系统，结果前三周提交量下降了 40%，因为大家不知道该从哪开始。

后来我调整了节奏：第一周先公布通道规则和判定逻辑（不发新系统），第二周上线新模板但保留旧通道，第三周切换系统，第四周开始统计新口径指标。整个过程放缓到一个月，但没有出现提交量断崖。

5. 自建 vs 采购：什么情况下不值得自建

如果你的立项流程有明显行业特殊性，比如涉及特殊的合规审批链、特殊的多级授权模型，自建或深度定制有合理性。

但如果需求本质是”立项信息结构化 + 与执行数据打通 + 权限与留痕”，这就是一个已经被充分解决的通用问题。自建在这类场景下的隐性成本主要不在开发，而在后续的字段变更、权限调整和合规适配。

我见过一个团队花四个月自建立项系统，上线一年后因为合规字段调整，又投入了两个月改造。而同类需求在用统一平台的方案下，调整通常是配置级别的工作。

八、总结：立项效率的独特判断与下一步

回到最开始的那个数字：27.4 个工作日、96% 通过率。这家公司的流程不是不努力，而是努力的方向错了，把精力放在了”让每个节点都签上字”，而不是”让决策信息足够充分”。

我想给出的核心判断有三条，它们可能和你在别处看到的不太一样。

第一，立项效率的瓶颈通常不在评审环节，而在分流设计和排队等待。我在案例中测得的数据是，把会开快只贡献了 0.8 个工作日，而分级授权贡献了 4.1 个工作日。如果你只有精力改一件事，改分流，别改会议。

第二，没有”立项后变更率”这个指标，立项流程优化就是盲飞。周期指标可以被人为压到任意好看的数字，但变更率不会撒谎。第 4 个月到第 5 个月的那次反弹，是我整个案例里最有价值的一次数据观察。

第三，预设终止条件（kill criteria）应该成为立项的必填字段。绝大多数立项模板问的是”要什么”，从不问”什么情况下停”。这一个字段的缺失，是很多项目停不下来的根本原因。

下一步怎么做，我给一个具体的、可以本周就开始的清单：

1. 拉一份过去 12 个月的立项清单，字段只需要项目名、立项日期、决议日期、投入金额、是否发生重大变更。如果这份清单你需要超过两天才能拉出来，说明”系统两张皮”的问题已经存在，先解决数据同源。
2. 算三个数：立项前置时间的中位数、一次通过率、立项后 30 天重大变更率。注意中位数比平均值更有意义，因为立项周期分布通常是右偏的。
3. 把立项按投入规模和可逆性分成两到三类，先不要急着定三档通道，两类就够。看看有多少项目其实可以走更轻的流程。
4. 在立项模板里加两个字段：owner（对结果负责的人）和 kill_criteria（预设终止条件）。只加这两个，其他先不动，运行两个月看效果。
5. 把决策会改成固定节奏。不管是每周三下午还是每两周一次，固定下来。这一项几乎不需要协调成本，但对前置时间的影响通常超过任何评审优化。

如果你只能从这篇文章里带走一句话，我希望是这句：立项流程的目标不是让项目快点被批准，而是让正确的项目快点被批准、让不该做的项目早点被拦住。做到前一半靠减节点，做到后一半靠加字段。两者同时做，才叫立项效率提升。