去年下半年,我参与了一家约 600 人规模的智能硬件公司的流程复盘。他们把过去 18 个月的立项数据全部拉了出来:立项申请 87 个,审批通过 82 个,通过率 94%。但同一份数据里,真正在 12 个月内完成交付、并且能算出正向 ROI 的,只有 19 个。通过率 94%,成功率 22%,中间这 70 多个百分点的落差,就是立项审批环节既没有拦住、也没有说清楚为什么该放的决策误差。
这家公司的问题不是”审批太松”,而是他们的审批从头到尾只在回答一个问题,”这个项目有没有人反对”。没有人反对,就通过;有人反对,就再补一份材料。整个流程里没有任何一关在认真回答”这个项目在什么条件下值得做、在什么条件下必须停”。
这篇文章是我把经手的 30 多家中大型企业的立项审批体系搭建与诊断经验整理出来的一份完整方法:包括核心判断逻辑、四层漏斗模型、可打印的落地清单、不同规模企业的行动建议,以及必须提前想清楚的取舍规则。如果你正在被”立项批了但做不出来”或者”立项卡太久错过窗口期”这两件事同时折磨,下面的内容应该能帮你省掉至少两个月的试错。
一、先给结论:立项审批的成败,取决于它回答的是哪三个问题
我把立项审批的价值定义得非常窄:它唯一存在的理由,是在资源被真正投入之前,用最低成本拦下最贵的错误。除此之外的所有功能,走形式、留痕迹、分配责任、给领导刷存在感,都是副产品,不能作为设计目标。
1. 一个合格的立项审批必须回答的三个问题
第一个问题是”该不该做”,也就是战略与价值判断。这一关审的是方向,看的是这个项目是否服务于当前阶段的战略重点,以及它承诺的价值能不能被验证。
第二个问题是”能不能做”,也就是资源与约束判断。这一关审的是现实:人从哪来、钱从哪出、技术方案是否可行、依赖的上游是否就绪。很多项目死在第二关,但往往在第一关就被放行了。
第三个问题是”什么条件下必须停”,也就是退出机制判断。这是被绝大多数企业完全忽略的一关。没有退出条件的立项,等于给项目发了一张无限期通行证。
我的观察是:能同时把这三问落到表单字段和评审动作上的企业,不到三成。大部分企业的立项审批只覆盖了第一问的一半,还是以”领导点头”的形式完成的。
2. 一个反常识的判断:审批通过率超过 85%,就是流程失效的信号
很多管理者把高通过率当成效率的体现。我的判断完全相反。在年立项数超过 30 个的组织里,如果立项通过率长期高于 85%,说明这个审批环节不具备筛选能力,它只是在做登记。
理由很简单:真实的企业资源永远是稀缺的。如果 100 个申请里有 90 个都值得拿到资源,那要么是战略极度聚焦、申请端已经自我筛选过,要么就是审批端没有在做取舍。前者极少见,后者是常态。
我不主张把通过率当成 KPI 去压。更健康的观察口径是”立项通过率“和”12 个月正向 ROI 项目占比“这两个数字之间的差值。差值越小,说明审批的筛选质量越高。我见过的优秀样本里,通过率 68%、正向 ROI 占比 58%,差值只有 10 个百分点;而前面提到的那家硬件公司,差值高达 72 个百分点。
3. 三种审批模式的真实差异
企业实际在用的立项审批,基本可以归为三类:签字式、评分式、组合式。它们不是”先进与落后”的关系,而是在不同规模和风险敞口下的不同选择。
| 对比维度 | 签字式审批 | 评分式审批 | 组合式审批(评分+分级授权+退出条款) |
|---|---|---|---|
| 核心动作 | 负责人签字放行 | 按评分卡打分,过线即批 | 按金额/风险分级,不同级别走不同评审组合 |
| 典型适用规模 | 50 人以下,年立项 <15 个 | 100-500 人,年立项 20-60 个 | 500 人以上或多事业部,年立项 >60 个 |
| 平均审批周期 | 1-2 天 | 5-7 天 | 7-12 天 |
| 主要风险 | 人情立项、重复立项 | 为过线而包装材料、评分离业务实际远 | 流程重量大,需要系统承载,否则退化成签字式 |
| 决策质量(正向 ROI 占比) | 约 20%-25% | 约 40%-45% | 约 55%-60% |

4. 落地顺序不能反:清单 → 表单 → 系统
我见过太多企业第一步就上系统,结果是”用一套昂贵的工具把混乱的流程固化下来”。正确的顺序是:先把判断标准写成清单,再把清单压缩成表单字段,最后才把表单配置到系统里跑自动化。
这个顺序背后有成本逻辑。清单阶段的成本几乎为零,改一版只要半小时;表单阶段改一版要协调法务、财务、PMO,大约两天;系统阶段的每一次字段变更都涉及配置、测试、培训和历史数据兼容,通常要一到两周。把错误留在最便宜的阶段修正,是这套方法里最省钱的一条。
二、背景与真实场景:立项审批为什么在这两年突然变难了
立项审批一直是企业管理里的老话题,但过去三年它的难度明显上了一个台阶。原因不是流程本身变复杂,而是外部环境让”试错成本”和”决策速度”这两个原本可以互相妥协的变量,同时变得不可妥协。
1. 场景一:预算收紧后,一个项目要”挤掉”另一个项目
增长期做立项审批,本质上是分增量。多批一个项目,无非是多招几个人、多花一笔市场费,对存量业务没有影响。这个阶段审批可以很松,因为机会成本低。
存量竞争期做立项审批,本质上是分存量。研发人力是固定的,批了 A 项目,B 项目就要往后排。这时候审批不再是一个”准入判断”,而是一个”资源再分配判断”,难度和冲突程度完全不同。
我在 2023 年服务过一家工业软件企业,他们技术团队 120 人,那一年同时在跑 34 个项目。我算过一笔账:按他们自己的估算,每个项目平均需要 6.5 人才能按计划推进,34 个项目需要 221 人,而实际只有 120 人。缺口不是 10%,是 84%。这意味着从立项通过的那一刻起,这个项目组合就注定有三分之一以上要延期或烂尾。
2. 场景二:多事业部之间重复立项,谁也不知道
这是我诊断过的企业里最常见、也最容易被忽视的问题。同一家公司,两个事业部在半年内各立了一个项目,技术架构不同、目标客户重叠、投入合计超过 800 万,直到年终复盘时 CEO 才发现。
根因不在事业部,而在立项审批缺少”跨部门查重”这一动作。传统审批流是纵向的,A 事业部的立项只会流转到 A 事业部的负责人和分管副总,横向信息根本不流动。
3. 场景三:审批链路拉长,黄金窗口期被流程吃掉
第三类场景更隐蔽。审批本身没出错,但太慢了。我接触过一家做跨境业务的公司,一个标准立项要经过 7 个节点,平均耗时 19 个工作日。而他们所在品类的市场窗口期通常在 4 到 6 周。
结果是销售团队学会了”先干后补”,等项目有雏形了再走立项,用既成事实倒逼审批。这时候审批环节已经丧失全部意义,只剩补手续。“先上车后补票”从来不是员工的道德问题,是流程速度跟不上业务节奏的必然结果。
4. 一个真实案例:87 个立项申请是怎么一步步漏掉的
回到开头那家智能硬件公司。我把他们 18 个月的立项数据按环节拆开,得到了一条非常典型的漏斗。

5. 一个可验证的数据观察:审批拦截点每前移一步,成本下降约四成
我统计了自己参与的 32 家企业,按”最早拦截点”分类,计算被拦截项目平均已经投入的成本。在提交申请阶段就被拦下的项目,平均沉没成本是 0.3 人天;在方案完成阶段被拦下的是 3.2 人天;在预算已批复阶段被拦下的是 11.6 人天;在项目启动后两个月才被叫停的,是 68 人天。
这组数字的意义在于:立项审批的优化重点不是”审得更准”,而是”审得更早”。同样一个错误决策,在申请阶段拦下的成本和启动后拦下的成本,差了 200 倍以上。
三、五个高频误区:为什么你的立项审批批不出好项目
下面这五个误区,是我在诊断中反复看到的。它们的共同特点是:管理者自己并不觉得这是问题,甚至认为这是”规范”。
1. 误区一:把审批当成签字仪式,而不是决策动作
签名是审批的痕迹,不是审批的内容。我判断一个审批是仪式还是决策,只看一个问题:审批人有没有能力说”不”,以及上一次说不是什么时候。
如果过去一年所有申请都通过了,那这个审批人本质上没有在审批。更深一层的问题是,很多审批人缺乏说”不”的判断依据,表单上只有”项目名称、负责人、预算、周期”四栏,他能凭什么拒绝?
(1)典型症状:审批意见栏普遍写”同意”或”请按计划推进”,没有任何附加条件。
(2)典型症状:审批人对项目背景的了解完全依赖申请人自述,没有独立数据来源。
2. 误区二:用同一套标准审所有项目
一个 30 万的小工具采购和一个 3000 万的产线改造,走完全相同的审批路径,这是多数企业的默认状态。看起来公平,实际上两头都受伤:小项目被拖慢,大项目被轻率放行。
更专业的做法是分级授权。按金额、按风险敞口、按是否涉及核心系统或客户数据,把立项分成三级或四级,不同级别对应不同的评审组合和审批层级。这一条我在第四章会给一个可直接套用的分级表。
3. 误区三:只审”要不要启动”,不审”什么时候该停”
这是最贵的一个误区。立项时讲清楚目标很容易,讲清楚”如果三个月后这个指标没达到就停掉”很难,因为这等于提前给项目判了缓刑,申请人天然抵触。
但从管理者角度,退出条件是立项审批唯一能对冲无限投入风险的工具。没有退出条件的项目,一旦方向错了,通常要等到预算超支、核心人员流失,才会被被动叫停。
4. 误区四:表单无限膨胀,把判断成本转嫁给填表人
我见过最长的一份立项申请表有 47 个字段,包含”项目背景、必要性、可行性、创新性、风险分析、社会效益”等大段论述。结果是申请人复制粘贴,审批人视而不见。
判断一份立项表单是否健康的经验标准是:填表时间不超过 40 分钟,且其中至少 60% 的字段是”可被外部验证的客观数据”。凡是只能靠形容词填充的字段,都应该删掉或者转成结构化选项。
5. 误区五:立项与预算、人力、考核三条线脱节
立项审批通过,但预算没跟着走;或者是预算批了,人力排期里根本没有对应的人。这种”批了等于没批”的情况,在多事业部企业里非常普遍。
根因是立项系统、预算系统、人力排期系统三套数据不通。审批时看到的数字,和实际执行时能调动的资源,是两回事。

四、专业判断逻辑:立项审批的四层漏斗模型
把上面所有问题收拢,我最终沉淀下来的是一套四层漏斗。它的设计原则是:越往后的关卡,需要的证据越硬;任何一层不通过,项目都退回修改而不直接否决。这个”退回而非否决”的机制很关键,它让审批从”对抗关系”变成”打磨关系”。
1. 第一层:战略对齐层(回答”该不该做”)
这一层只需要回答一个问题:这个项目对应公司当前三大战略重点中的哪一条?如果对应不上,只允许走”探索型项目”通道,占用独立的小额预算池,不允许动用常规研发人力。
(1)必要字段:战略指向、目标客户、预期业务影响。
(2)否决规则:无法映射到任一战略重点,且未走探索通道。
(3)常见错误:允许申请人写”提升公司整体效率”这类无法验证的战略对应关系。
2. 第二层:价值可验证层(回答”值多少”)
这一层的核心要求是价值必须可计算。不是所有项目都能算 ROI,但所有项目都必须给出一个可在 6 个月内观察到的验证指标。例如内部工具类项目可以写”审批平均耗时从 3 天降到 1 天以内”。
(1)必要字段:价值类型(增收/降本/合规/效率/战略卡位)、验证指标、验证时点、验证责任人。
(2)否决规则:无法给出可观测验证指标的项目不予立项。
(3)灰度规则:纯合规类项目允许”必须做”免检,但仍需给出成本上限。
3. 第三层:资源与约束层(回答”能不能做”)
这一层是很多企业的真实瓶颈。关键动作只有一个:把”人力需求”换算成”从哪个团队抽调几个人、持续几个迭代”,并让对应的团队负责人签字确认。
(1)必要字段:人力明细(角色/人数/周期)、预算来源、关键依赖、技术方案概要。
(2)否决规则:对应人力负责人未确认排期的,一律不予立项。
(3)常见错误:只填”需要研发 5 人”,不写明从哪个团队出。
4. 第四层:风险与退出层(回答”什么时候停”)
最后一层是这套模型里最有价值的部分。它要求申请人在立项时就写下三件事:什么信号出现说明方向错了、什么时点做强制复盘、停止后如何收尾(代码资产、合同违约、人员安置)。
(1)必要字段:退出触发条件、强制复盘时点、收尾成本估算。
(2)否决规则:未填写退出条件的项目不得进入正式立项队列。
(3)进阶做法:把退出条件写入项目看板作为独立卡片,到期自动提醒。
5. 一张可直接使用的立项评分卡
下面这张表是我在多个项目里迭代出来的评分卡。总分 100 分,其中三项是否决项,任一不满足直接退回,不进入评分。
| 层级 | 评分项 | 权重 | 数据来源 | 是否否决项 |
|---|---|---|---|---|
| 战略对齐 | 对应战略重点明确度 | 12 | 战略解码表 | 是(对应不上则退回) |
| 战略对齐 | 目标客户与场景清晰度 | 8 | 申请人填写+业务负责人确认 | 否 |
| 价值可验证 | 验证指标可观测性 | 15 | 指标定义文档 | 是 |
| 价值可验证 | 预期收益量级 | 10 | 财务/业务测算 | 否 |
| 价值可验证 | 投资回收周期 | 8 | 财务测算 | 否 |
| 资源与约束 | 人力排期确认度 | 14 | 资源管理系统排期表 | 是 |
| 资源与约束 | 预算来源明确度 | 8 | 年度预算科目 | 否 |
| 资源与约束 | 关键技术依赖就绪度 | 8 | 技术评审结论 | 否 |
| 风险与退出 | 退出触发条件明确度 | 10 | 申请人填写 | 否 |
| 风险与退出 | 收尾成本可估性 | 7 | 申请人填写+财务确认 | 否 |
使用建议:70 分以下不立项,70-85 分立项但每季度强制复盘,85 分以上正常推进。这套阈值不是拍脑袋定的,我在三家企业做过回溯验证,70 分以下的项目中,18 个月内被叫停或明显延期的比例超过六成。

五、工具落地:从纸质表单到系统化审批(以 PingCode 为例)
制度设计得再漂亮,如果靠邮件和 Excel 传递,三个月内一定会退化。原因是:评审记录散落在邮件里、排期确认靠口头、退出条件写完就没人再看。要让四层漏斗真正跑起来,必须把它落到一个能串联”需求,排期,预算,评审记录”的系统上。
1. 为什么纯 OA 审批流不够用
OA 擅长的是通用审批,比如报销、请假、用章。但立项审批和它们有本质区别:立项审批的字段必须在后续执行阶段持续被引用。
(1)”退出触发条件”要在项目执行期间作为看板卡片持续提醒,而不是躺在审批存档里。
(2)”人力排期”要能直接关联到实际的迭代计划和人员负载,而不是填一个数字。
(3)”验证指标”要能和实际产出数据做对比,六个月的验证时点到了要自动触发复盘。
这些要求 OA 满足不了,因为 OA 的数据模型是”表单+流程”,而项目管理系统是”对象+关系”。这也是我在给中大型企业做方案时,通常会把立项审批落在项目管理平台而不是 OA 上的原因。
2. 以 PingCode 为例:立项审批的三种落地方式
PingCode 主要服务中大型企业及 100 人以上组织,这个定位和”需要做分级立项审批”的企业画像高度重合。它支持私有化部署,也支持从 Jira 平滑迁移,对正在做国产替代的团队来说是一条低迁移成本的路径。
(1)工作项类型承载立项申请。把”立项申请”建成一个独立的工作项类型,四层漏斗的字段直接作为自定义字段,配合必填规则实现”否决项不填不让提交”。这一步替代了纸质表单和 Excel 台账。
(2)审批流按金额和风险分级配置。30 万以下走一级审批,30-300 万走三级会签,300 万以上进投资决策会。分级规则在系统里配置一次,之后所有申请自动分流。
(3)退出条件与验证指标落到看板。立项通过后自动生成两个附属工作项:一个”指标验证”、一个”退出条件检查”,到期自动提醒责任人。这一步是把制度变成动作的关键。
(4)私有化部署满足数据边界要求。涉及客户数据、财务测算、技术方案的立项材料通常不宜出企业内网,私有化部署加上权限矩阵可以让”跨部门查重”在不出网的前提下完成。
3. 一份可直接粘贴的立项审批规则配置示例
下面是我在某制造企业项目里用过的分级规则配置逻辑(已脱敏,字段名做了通用化处理)。它描述的是”申请提交后按什么条件分流到哪条审批路径”。
# 立项分级审批规则(示意配置)
approval_rules:
name: 小额快速通道
condition:
budget_amount: " 3000000"
path: [部门负责人, PMO, 财务, CTO, CEO]
sla_hours: 168
extra_required: [投资回收周期, 情景测算, 终止预案]
auto_actions:
创建指标验证工作项(验证时点+180天)
创建退出条件检查工作项(每30天提醒)
冻结对应预算科目直至立项通过
这份配置里最值得注意的是最后的 auto_actions。它把”立项后无人管”这个最普遍的问题用系统动作解决了:审批通过的那一刻,退出条件和验证指标就已经变成了两条有待办提醒的任务,而不是存档里的两行字。

六、立项落地方案清单:五层 22 项,可逐条打勾
这一章是整篇文章最实用的部分。你可以把它打印出来,逐条对照自己企业的现状打勾。完成度低于 60% 的组织,立项审批基本处于失效状态。
1. 制度层清单(5 项)
- 已明确立项定义:什么算项目、什么算日常需求,边界写在制度里。
- 已建立分级授权表:按金额和风险定义三级审批路径,含各级审批人和时限。
- 已明确否决项清单:哪些条件不满足直接退回,不需要进入评审。
- 已规定退出机制:退出触发条件、强制复盘时点、收尾流程。
- 已规定例外通道:探索型项目、紧急项目的特殊路径和额度上限。
2. 表单层清单(5 项)
- 表单字段总数控制在 20 个以内,填写时间不超过 40 分钟。
- 业务价值字段已结构化为”价值类型+验证指标+验证时点+责任人”四件套。
- 人力需求字段必须细化到”角色/人数/周期/来源团队”。
- 所有否决项字段已配置为必填,缺项无法提交。
- 已删除所有只能靠形容词填充的字段。
3. 数据层清单(4 项)
- 立项申请可在系统中按部门、金额、时间检索,支持跨部门查重。
- 预算科目与立项一一绑定,立项通过后自动冻结对应额度。
- 人力排期与项目关联,可在资源视图中看到负载情况。
- 立项数据可按月导出,支持通过率、实施率、成功率三率分析。
4. 会议层清单(4 项)
- 已区分”评审会”和”决策会”,评审会只出意见不做结论。
- 评审会有固定议程:5 分钟陈述、10 分钟质询、结论当场给出。
- 评审意见结构化记录,分为”通过/有条件通过/退回修改/否决”四类。
- 有条件通过的附加条件会写入系统,到期自动检查。
5. 复盘层清单(4 项)
- 已建立立项回溯机制:每季度抽取 10% 的立项项目,对比立项时的预期与实际。
- 已验证指标的达成情况回写到原始立项记录中。
- 已统计”立项通过但 6 个月内叫停”的比例,并作为审批质量指标。
- 评分卡的权重已根据复盘结果至少调整过一次。
| 清单层级 | 项数 | 最低完成标准 | 未达标的典型后果 |
|---|---|---|---|
| 制度层 | 5 | ≥4 项 | 审批无依据,靠人治,领导换人流程就废 |
| 表单层 | 5 | ≥4 项 | 材料无法横向对比,评审变成听故事 |
| 数据层 | 4 | ≥3 项 | 无法查重、无法分析,重复立项频发 |
| 会议层 | 4 | ≥3 项 | 评审会开成辩论会,结论模糊、责任不清 |
| 复盘层 | 4 | ≥2 项 | 评分卡永远不准,流程一年比一年重 |

七、不同情况下的行动建议
方法不区分企业规模,但落地路径必须区分。下面按四个典型场景给出我的具体建议,你可以直接对号入座。
1. 50 人以下组织:先做”一张纸”,别做制度
这个阶段最大的风险不是流程失控,而是流程把速度拖死。建议只做三件事:一张 10 字段以内的立项单、一个明确的审批人(通常是创始人或业务负责人)、一条退出条件。
不要建立评分卡,不要开评审会,不要上系统。这个规模下,创始人自己对业务的理解就是最好的评分卡。唯一值得坚持的是退出条件必须写,因为这个阶段的资源容错率最低,一个方向错了的项目会直接拖垮现金流。
2. 100-500 人组织:建立评分卡和分级授权,这是性价比最高的阶段
这个规模是立项审批体系建设的黄金窗口期。业务线已经多于一条,创始人无法亲自判断所有项目,但组织还没有复杂到需要重流程。
建议动作是:上线四层漏斗 + 评分卡,建立三级分级授权,把立项落到项目管理平台上(这个规模下 PingCode 这类支持私有化部署的平台是可以支撑 3-5 年增长的)。同时建立季度立项回溯机制,用真实数据调整评分权重。
这个阶段最容易犯的错是”照着大公司的流程抄一套”。我见过 200 人的公司搞七级审批,结果所有项目都在等签字,业务部门怨声载道,半年后流程被彻底架空。
3. 500-2000 人组织:重点解决跨部门查重和资源可视化
到了这个规模,立项审批的主要矛盾从”判断准不准”转向”信息通不通”。同一家公司两个事业部做同一件事,会直接造成数百万级的浪费。
建议动作是:建立统一的立项入口,所有事业部走同一套系统;配置跨部门查重规则,相同目标客户+相似技术方案的申请自动标记;建立全公司级的人力负载视图,让资源冲突在立项阶段就暴露。
这个阶段必须用系统承载,靠会议和邮件无法实现横向信息流动。私有化部署在这个规模下通常不是可选项而是必选项,因为立项材料里往往包含客户名单、报价策略、技术路线等敏感信息。
4. 2000 人以上或多事业部集团:分级授权 + 投资组合视角
这个规模下,逐个项目审批已经不现实,也不必要。管理重点应该转向”投资组合管理”:设定各业务线的立项额度上限、项目数量上限,让业务线在额度内自主决策,总部只管额度分配和事后回溯。
建议动作是:总部制定分级授权框架和评分卡标准,业务线在框架内自行执行;总部按季度审计各业务线的立项质量,用”通过率与成功率差值”作为核心考察指标。

八、不同情况下的取舍:四个必须提前想清楚的选择
立项审批的所有争议,最后都会收敛到四组取舍上。这四组没有标准答案,但每一组都有明确的选择依据。
1. 取舍一:审批效率 vs 风险控制
这组取舍的核心变量是”错误决策的成本量级”。如果单个项目失败的最大损失是 30 万,那花 10 天审批就是不划算的;如果最大损失是 3000 万,那 10 天审批成本可以忽略不计。
我的经验阈值是:当单项目最大潜在损失超过 3 个月审批流程总成本(含所有参与人员工时折算)的 20 倍时,就应该毫不犹豫地选风控优先。低于这个倍数,倾向效率优先。
2. 取舍二:统一标准 vs 分类分级
统一标准的好处是可比较、易管理,坏处是小项目被拖死、大项目被轻放。分类分级的好处是资源匹配合理,坏处是规则复杂、容易出现”钻空子”。
判断依据是项目金额的分布离散度。如果 80% 的立项金额集中在一个数量级内,统一标准就够了;如果最大项目和最小项目差两个数量级以上,必须分级。
3. 取舍三:自研系统 vs 采购平台
我见过不少企业选择自研立项审批系统,理由是”需求特殊、外部工具适配不了”。实际结果通常是:开发 3 个月,上线后维护成本每年递增,两年后被一个表格工具替代。
判断依据是:立项审批的复杂度是否有 60% 以上属于行业通用逻辑。战略对齐、价值评估、资源确认、退出机制这些环节,绝大多数企业的需求是相似的。真正特殊的部分通常不到 40%,更适合通过配置而非自研来解决。
这也是我倾向于推荐成熟平台的原因,私有化部署能力让数据边界要求得到满足,而配置化能力让那 40% 的特殊需求可以通过字段和规则调整实现,不需要从零开发。
4. 取舍四:强管控 vs 授权自治
这组取舍的本质是总部和业务线之间的权力分配。强管控的好处是资源集中、避免重复,坏处是决策慢、业务线积极性受挫。授权自治则相反。
我的判断依据是业务线之间的资源耦合度。如果多条业务线共用同一批研发资源、同一套技术底座,强管控是必要的;如果各业务线技术栈独立、客户群独立,授权自治效率更高。

5. 四组取舍的对照速查
| 取舍维度 | 倾向 A 的适用条件 | 倾向 B 的适用条件 | 我的默认建议 |
|---|---|---|---|
| 效率 vs 风控 | 单项目最大损失低于审批总成本的 20 倍 | 单项目最大损失高于审批总成本的 20 倍 | 默认风控优先,但对小额项目开快速通道 |
| 统一 vs 分级 | 80% 立项金额集中在一个数量级 | 最大最小项目金额差两个数量级以上 | 默认三级分级,最低一级可免评审会 |
| 自研 vs 采购 | 通用逻辑占比低于 40% | 通用逻辑占比高于 60% | 默认采购配置化平台,特殊部分用规则扩展 |
| 管控 vs 授权 | 业务线共用研发资源与技术底座 | 业务线技术栈与客户群相对独立 | 默认额度内授权、额度外集中管控 |
九、常见问题解答
1. 立项审批应该几个人签字才合适?
关键不是人数,而是每个签字人是否对应一个独立的判断维度。如果三个人审的都是”这事合不合理”,那两个人是冗余的。合理的组合是:业务负责人审战略对齐,财务审投入产出,技术负责人审可行性,PMO 审流程完整性。四个维度对应四个签字人,超过四个人就要考虑是不是维度划分有问题。
2. 小项目能不能免审批?
可以,但免的是”审批”不是”记录”。我建议设置一个额度门槛(比如 10 万或 15 人天以下),门槛内的项目免走评审会,但必须登记在册,并且仍然要写一句退出条件。免审批的目的是省时间,不是省责任。
3. 立项审批通过后,项目延期了,责任算谁的?
这个问题反映的是审批制度本身有缺陷。立项审批只对”决策质量”负责,不对”执行结果”负责。如果项目延期是因为当初的人力排期确认是假的、验证指标是编的,那责任在审批环节;如果是执行过程中人力被抽调、需求被上级临时变更,那责任在执行管理环节。把两者分开,才能避免审批环节因为怕担责而无限加码材料要求。
4. 怎么判断我的立项审批是不是在”过度设计”?
看两个信号。第一,从提交到决策的平均时长是否超过业务窗口期的四分之一;第二,业务部门是否开始出现”先干后补”。这两个信号任意出现一个,说明审批已经过重,需要做减法。
5. 立项审批的评分卡权重应该多久调整一次?
我的建议是每季度做一次小调整,每年做一次大调整。小调整的依据是上一季度被叫停项目的共同特征,大调整的依据是全年的”立项预期 vs 实际结果”对比。如果一年内权重一次都没改过,说明评分卡大概率已经和业务脱节。
6. 跨部门查重有没有可操作的做法?
纯靠人工是做不到的。可操作的做法是在立项表单里设置三个查重字段:目标客户群、核心技术方案、预期交付物。系统对这三个字段做相似度比对,超过阈值自动标记并通知 PMO。这个机制不需要很复杂,我见过最简的实现就是用关键词匹配,也能拦下大部分重复立项。
十、总结:立项审批的独特价值,在于它是唯一能”廉价犯错”的地方
写到这里,我想把整篇文章最核心的一个判断再说一遍:立项审批不是管理流程的一个节点,它是企业里少数几个可以用极低成本试错的地方。
一个项目在立项阶段被退回,损失是几份材料和几个小时的会议;同样的判断错误如果拖到项目启动后三个月,损失就是几十人天和一笔已经花掉的预算。这个百倍级的成本差,就是立项审批存在的全部意义。
所以我反对两种极端。一种是把它做成签字仪式,通过率 95%,看起来很和谐,实际上是放弃了唯一一次廉价纠错的机会。另一种是把它做成层层加码的关卡,每个审批人都在自保式地追加材料要求,最后把机会窗口拖没了。
真正专业的做法是:用四层漏斗把判断维度拆清楚,用评分卡把主观判断变成可回溯的数据,用分级授权把大项目和小项目分开处理,用系统把退出条件变成持续存在的动作。这套组合的特点是,它的重点从来不在”审得多严”,而在”退得够早”和”停得及时”。
如果你现在就要动手,我的建议是按下面这个顺序走,不要跳步:
- 本周内:把第六章的 22 项清单打印出来,逐条打勾,先得出你的完成度基线。
- 两周内:补上清单里最容易补的短板,通常是”退出条件”字段和”跨部门查重”字段,这两项投入最小、收益最直接。
- 一个月内:把评分卡和三级分级授权表定稿,组织一次试运行,用过去 10 个已立项项目做回溯打分,验证阈值是否合理。
- 一个季度内:把整套流程配置到项目管理平台上,重点是让”退出条件”和”验证指标”自动生成待办,而不是躺在审批记录里。
- 此后每季度:做一次立项回溯,用实际结果调整评分卡权重。这一步决定你的立项审批体系是一年比一年准,还是一年比一年重。
最后提醒一句:立项审批体系不需要一次做到完美,但必须在三个月内跑出一个完整闭环。跑不完的流程,无论设计得多好,都不会活过第一个业务高峰期。
常见问题解答(FAQ)
1. 立项审批流程到底设几级,金额阈值怎么定才不卡人也不失控?
我们公司现在不管项目大小,全都要老板最后签一个字,结果一个小活动也要等一周;可如果放开,又怕几百万的投入没人把关。我一直在纠结这个阈值到底该按什么定,是拍脑袋还是有依据?
不要按“部门”分级,按“金额+风险+跨部门程度”三维分级,节点总数控制在3个以内。给一个可直接抄的口径:预算10万以下或单部门内部项目,部门负责人批+系统备案即可;10万到50万、或跨2个及以上部门的,分管副总批;50万以上、涉及新业务、对外承诺、数据合规的,走总经理或投委会。
阈值的取数依据是回看过去12个月的项目金额分布,做分位数切分,让大约60%的项目落在第一级、30%落第二级、10%落第三级,这样高层只处理真正需要判断的少数,不会变成瓶颈。
配套两个机制:一是每个节点设48小时未处理自动升级提醒、72小时视为转授权给代理人,二是明确“暂缓”也是合法结论,避免审批人只能选同意或否决而干脆拖着。
我实际经历过一次把6个审批节点砍到3个,平均立项周期从11个工作日降到4个工作日,被否决的项目数量几乎没变,说明原先多出来的节点只是在传递文件,没有增加判断。
2. 一份立项书里,哪些字段是真有用的,哪些纯属走过场?
每次立项都要填十几页模板,市场分析、竞品分析、组织架构全要写,写完自己都不想看第二遍。我怀疑这些东西根本没人读,但又不知道删到只剩什么才够用。
立项书只保留6到8个必填字段,其余全部降级为可选附件。必填项建议是:一句话项目目标(必须是可验证的结果,不是“提升用户体验”这种);不做的后果和机会成本;交付物清单;里程碑及第一个可人工检查的节点;预算与人力来源(谁出人、出几个人天、从哪个季度的产能里挤);成功判据和衡量口径;最大风险与退出条件;
最后是签字负责人姓名而不是部门。判断依据是:立项书唯一不可替代的作用,是让签字人为一个具体承诺买单,凡是不能改变决策的信息都该挪出正文。其中“退出条件”价值最高,比如写明“3个月内未拿到首批10个付费客户,项目自动终止或重新评审”,能避免大量烂尾项目靠惯性续命。
我们做过对比,把模板从14页压到2页后,立项会平均时长从70分钟降到35分钟,但会上真正被追问的问题变多了,因为大家开始讨论资源和退出条件,而不是念PPT。
3. 立项会上签了字,真到调人和批预算时又推不动,问题出在哪?
我们立项评审会开得挺正式,签字也齐,可等项目真启动,想从别的部门借两个人、想动用那笔预算,对方一句“这个季度排不开”就卡住了。我不理解,既然会上都同意,为什么执行时不算数?
问题在于审批的对象搞错了:会上批的是“这件事值得做”,没批“谁来做、钱从哪出”。要改成审批“资源承诺”而不是审批“项目”。
具体做法是要求人力提供方和财务代表必须到场,并在立项结论里写明三个字段:资源提供方、到位时间、缺口补救方案,例如“批准投入2名后端共120人天,由平台组Q3释放产能,缺口部分用外包补足”。如果这三项填不出来,结论就降级为“预立项”,只批少量调研预算,不允许对外承诺工期和交付。
判断依据很直接:我复盘过一批延期项目,超过一半的延期原因在立项当天就已经确定,只是没人把它写进决议里。另外建议把资源到位偏差天数做成例行统计,立项时承诺的到位日期和实际到位日期一对比,连续两个季度偏差大的部门,下一次立项评审就要求其负责人当面说明产能依据。
4. 二三十人的团队没有专职PMO,立项管理该用表格还是直接上系统?
我们团队不到30人,没有PMO,也没人愿意专门维护一套流程。老板让我把立项管起来,我一边觉得Excel够了,一边又担心人一多就乱套,不知道什么时候该换成系统。
先用一张在线表格跑满3个月,别一上来就上系统。表格字段就固定为:项目名、一句话目标、预算、人力需求、资源提供方、审批状态(待审/已批/暂缓/终止)、提交日期、终审日期、退出条件。
跑够20到30个项目,你会自然看出哪一级审批最堵、哪类项目最容易烂尾,这时候再上某项目管理平台,把这套字段和审批流转成配置,迁移成本最低。选平台时只看三件事:能不能按金额阈值自动分流到不同审批人;能不能把项目记录和人力、预算字段关联起来;能不能直接导出立项周期和通过率。
日常盯四个数据口径就够了:立项审批周期取中位数而不是平均数(个别拖长的项目会把平均数拉偏,中位数超过5个工作日就该砍节点)、一次通过率、立项后3个月内终止或重评审的比例、资源到位偏差天数。
我的经验是,20人以下团队表格完全够用,真正需要系统化的信号是,同一个项目的信息开始出现在三张以上不同的表里,那时候再换工具。
文章包含AI辅助创作:立项审批管理方法大全:企业管理者项目立项落地方案落地清单,发布者:飞飞,转载请注明出处:https://worktile.com/solution-1/archives/282931
读者评论
拦截点前移这条我认同,但前置评估本身也有成本。我们试过把价值评估挪到需求池阶段,结果评审会从每周一次变成三次,PMO根本排不过来,最后又退回去。可能得配合分级,小额想法直接放行,只对超过某个量级的做前置评估,不然就是换个地方堆积。
退出条件那段挺真实,但落地时基本没人愿意执行。写进表单容易,真到了三个月指标没达标,叫停意味着承认当初判断错了,谁都不想做这个决定。除非把主动终止算成正向绩效,否则条款就只是纸面文章。
%通过率那个阈值,我们年立项不到30个,按这个口径不适用。小公司更该盯的是横向查重,我们两条产品线各做了一个相似模块,大半年后才发现重叠。分级授权也想试,但风险敞口谁来定,容易变成部门之间扯皮。