去年 Q3，我接手了一个 ERP 实施项目的复盘。项目原计划 10 月 15 日上线，实际延期到 11 月 28 日，超期 44 天。但翻开每周的进度周报，上线前一周的"整体完成度"还写着 82%。更离谱的是，延期被发现的时间点是 10 月 8 日，距离原定上线只剩 7 天。也就是说，这个项目在前 5 个月里，所有进度数据都在告诉管理层"一切正常"，直到最后一刻才集体爆雷。
这不是个例。我后来陆续复盘过十几个实施交付项目，发现一个高度一致的规律：实施团队的进度问题，极少是"计划没排好"，绝大多数是"偏差发现太晚"。而"发现太晚"的根因，往往不是团队不努力，而是进度数据和真实进度之间，从一开始就存在系统性失真。
这篇文章不讲甘特图怎么画、WBS 怎么拆，那些内容已经足够多。我想讲的是另一件事：怎么用一套数据分析流程，把"进度是不是要黄了"这个问题，变成一张每天或每周能自动回答的表，并且规定好谁看到红灯之后该干什么。全文会围绕取数口径、偏差指标、预警阈值、升级动作这条闭环来展开，工具层面以 PingCode 这类支持私有化部署、面向中大型实施团队的项目管理平台为例，说明数据是怎么被采集和加工的。
一、先给结论：进度管理的本质是偏差管理，不是完成率管理
如果只能记住一句话，我希望是这句："完成率"是给汇报用的，"偏差率"才是给决策用的。
大多数实施团队监控的是"完成率"，任务完成了多少百分比。这个数字有两个致命问题：第一，它由执行人自己填报，天然倾向于报高；第二，它是绝对值，没有和"应该完成多少"做对比，看不出节奏。
举个直观的例子。一个 6 个月的项目，第 3 个月末完成率 55%，听起来还行。但如果按计划这个节点应该完成 70%，那实际偏差就是 -21.4%，属于严重落后。反过来，如果计划本来就只有 50%，那 55% 反而是超前。脱离计划基线谈完成率，等于没有信息。
所以我在所有项目里都坚持三个原则：
- 一切进度指标都要带基线：没有"计划值"做分母，任何完成数据都不进入决策视野。
- 偏差指标优先于绝对值指标：SPI、进度偏差率、里程碑达成率，优先级高于"完成百分比"。
- 数据终点必须是动作：每个红灯指标背后，都要绑定"谁、在多长时间内、做什么"。
这三条原则决定了后面所有流程的设计方向。下面我先讲清楚进度数据为什么会失真，再讲怎么修。
二、背景与真实场景：实施团队的进度数据为什么天然不可信
在讲数据分析流程之前，必须先承认一个现实：实施团队拿到的进度数据，出厂就是脏的。如果不处理这个前提，后面再漂亮的看板都是自欺欺人。
1. "完成度"由人填报，必然存在系统性高报
我做过一个不算严谨但很有说服力的内部观察：在某实施团队里，让成员自评任务完成度，同时用客观信号（交付物是否被客户签收、代码是否合并、配置是否通过 UAT）交叉验证，两者平均差距在 12-18 个百分点，个别任务差距超过 40%。
原因不难理解。执行人面临的是"今天的压力"，报 80% 可以避免被追问，报 50% 会立刻被拉去开会。这种激励结构下，自报完成度必然向上偏移，且越接近截止日期，偏移越大，因为大家都在赌"再给我几天就能补上"。
2. 数据散落在多个系统，口径各说各话
典型的实施项目，进度相关数据至少散在五六个地方：项目管理工具里的任务状态、工时系统里的投入工时、交付系统里的里程碑验收记录、CRM 里的合同节点、财务系统里的收款进度。每个系统对"完成"的定义都不一样。
项目管理工具里"任务状态=已完成"，在交付系统里可能"交付物还没验收"，在财务口径里"款项还没到"。当这三个数据同时摆在会上，大家讨论的其实不是同一件事，却以为在讨论进度。
3. 只有"完成视角"，没有"偏差视角"
这是最隐蔽也最致命的一条。很多团队的周报结构是"本周完成 X，累计完成 Y%"，通篇没有"计划应该是多少、偏差多少、偏差在扩大还是收敛"。这种报告只能回答"做了多少"，无法回答"要不要干预"。
我把这三类失真画成一张对比图，方便你对照自己团队的情况。
三、常见误区：大多数团队的"数据化进度管理"卡在哪
我在复盘里见过太多"看起来很努力"的做法，最后都失败了。把高频误区集中列出来，你可以对照自查。
1. 一上来就追求全自动实时看板
很多团队第一反应是"上个 BI，把所有数据实时打通"。结果是：数据源没治理干净，看板每天刷新，但刷新出来的还是错的数据。花了三个月搭平台，管理层看了两周就没人看了。数据化进度管理的第一步不是可视化，是口径统一。
2. 指标越多越安心
我见过一张项目看板有 27 个指标。结果没有一个指标有人真正在看，因为谁也不知道哪个该报警。指标的价值不在数量，在于每个指标都有明确的阈值和责任人。超过 8 个核心指标，通常就开始失效。
3. 只做报表，不改流程
最典型的现象：看板做得漂漂亮亮，红灯也亮了，但没有任何人的工作因此改变。数据分析和进度管理"两张皮"的核心原因就在这里，报表没有绑定升级机制。红灯亮起后，如果没有"谁在 24 小时内做什么"，这个红灯就只是装饰。
4. 把 EVM 当成教科书公式抄
挣值管理（EVM）是好东西，但直接照搬 PV/EV/AC 三件套到实施项目里，往往会因为"EV 无法客观计量"而流于形式。实施项目的交付物边界模糊，EV 的取值口径需要重新设计，不能直接用教科书公式。
四、专业判断逻辑：先统一口径，再谈分析
接下来是我认为全文最硬的部分。如果这一节做对了，后面的流程就是水到渠成；做错了，后面全是无用功。
1. 先定义"什么是完成"，三种度量口径及适用场景
实施项目里，"完成"至少有三种可量化口径，各有适用边界，不能混用：
| 度量口径 | 定义 | 适用场景 | 主要缺陷 |
|---|---|---|---|
| 任务数口径 | 已完成任务数 / 计划任务数 | 任务颗粒度均匀、拆分规范的项目 | 任务大小差异大时严重失真 |
| 工时口径 | 已完成任务预估工时 / 总预估工时 | 人力密集、工时管理成熟的项目 | 依赖工时填报准确性 |
| 里程碑口径 | 已验收里程碑 / 计划里程碑 | 阶段性强、有客户验收节点的项目 | 颗粒度粗，不适合日/周监控 |
我的建议是组合使用：用任务数口径做周级监控，用里程碑口径做阶段验收判断，用工时口径做资源负载分析。三者交叉验证，任何两个口径出现大幅背离，就说明数据有问题。
2. PV / EV / AC 在实施项目里怎么落地
EVM 的三个基础量，在实施项目里需要做简化映射。以下口径是本人在实施项目中的自定义简化，非 PMBOK 教科书原文，使用时需按项目特性校准。
- PV（计划价值）：截至某时点，计划应完成的任务预估工时总和。
- EV（挣值）：截至某时点，实际已完成任务对应的预估工时总和，注意，是"已完成"而非"已开始"。
- AC（实际成本）：截至某时点，实际投入在该项目上的工时总和。
派生指标里，我最常用的是 SPI（进度绩效指数）= EV / PV。SPI < 1 表示进度落后，SPI > 1 表示超前。相比"完成率"，SPI 的价值在于它自动带入了计划基线，直接回答"落后了多少"。
但要提醒一句：EV 的客观性依赖"完成"的定义是否客观。如果"完成"还是靠人填报，SPI 一样会失真。所以第 2.3 节里，我会强调用客观信号交叉验证 EV。
3. 最小可用数据集：只需要 6 个字段
不必一上来就整合全公司数据。一个能跑起来的进度分析，最小数据集只需要 6 个字段：
- 任务唯一 ID
- 所属项目 / 阶段
- 计划开始 / 计划完成时间
- 实际完成时间（或状态）
- 任务预估工时
- 责任人 / 责任团队
这 6 个字段就能算出 SPI、偏差率、里程碑达成率、责任人维度的落后分布。不要为了"看起来完整"而把字段扩到二十几个，那只会让治理成本失控。
以 PingCode 为例，它的任务实体本身就带计划/实际时间、预估工时、责任人字段，并且支持通过 API 或数据导出把这些字段送进下游分析。对中大型实施团队来说，这种结构化数据源是后续偏差分析的前提。
五、进度数据分析全流程：本文自定义的六步闭环
下面这套六步流程是我在多个实施项目中逐步打磨出来的，属于本文自定义划分，与市面上"采集，清洗，建模，分析，可视化，决策"的常见口径不完全一致，我把它调整得更贴合实施交付场景。请把它当作一套可执行的框架，而不是标准答案。
1. 采集：把数据从工具和系统里稳定取出来
采集阶段的核心不是"取全"，而是"取稳"。我建议先锁定两个数据源：项目管理工具（任务计划与实际状态）和交付/验收系统（里程碑签字记录）。工时系统和财务系统作为第二阶段接入。
在 PingCode 里，任务、迭代、里程碑数据可以直接通过 API 或数据导出获取，支持按项目、按时间窗口批量拉取。对私有化部署的中大型团队，这意味着数据可以留在内网做分析，不受外部服务波动影响。采集阶段要建立"定时任务 + 失败告警"，否则数据一旦断裂，看板会悄悄过期而没人发现。
2. 清洗：处理重复任务和跨项目工时归属
清洗阶段的三个高频问题：任务重复（同一任务被拆到多个看板）、跨项目工时归属错误、状态字段不一致（"已完成"和"Done"混用）。
实操上，我建议用任务唯一 ID 做主键去重，用"任务→项目"映射表统一归口，用状态映射字典把多套状态值归一。清洗规则要写在文档里，不能只存在于某个人的脚本里，否则一旦这个人休假，整套流程就断。
3. 建模：算 SPI、偏差率、里程碑达成率
建模阶段就是把清洗后的数据算成指标。核心三个：
- SPI（进度绩效指数）= EV / PV，反映整体进度效率。
- 进度偏差率 =（实际完成量 − 计划完成量）/ 计划完成量，反映偏离基线的相对幅度。
- 里程碑达成率 = 按期达成里程碑数 / 计划达成里程碑数，反映阶段性交付健康度。
这里要特别强调客观信号交叉验证。EV 不能只用自报的"完成"，要叠加交付物验收、UAT 通过、代码合并等客观信号。当自报完成度与客观信号背离超过阈值（比如 20 个百分点），该任务应标记为"数据存疑"，不进入 SPI 计算。
4. 分析：区分"真落后"和"计划本身不合理"
这是最需要专业判断的一步。SPI < 1 有两种可能：团队确实落后，或者计划本身排得太激进。如果不区分这两者，纠偏动作会打错方向。
我的判断逻辑是：看偏差是持续扩大还是稳定收敛。如果从项目第 2 周起 SPI 就稳定在 0.85 且没恶化，很可能是计划基线过于乐观，该做的是修基线；如果 SPI 在最近 3 周从 0.95 滑到 0.78，那是真实的执行问题，该做的是查阻力和加资源。
5. 可视化：一页看板的三层信息
看板不要贪多，一页就够，分三层：
- 顶层红黄绿：项目整体 SPI、偏差率、里程碑达成率的当前值。
- 中层趋势：最近 4-8 周 SPI 的变化曲线，看方向而不只看点位。
- 底层责任到人：按责任人/团队列出落后任务分布，直接指向升级对象。
我坚持的原则是：看板的每个数字都要能下钻到具体的任务和人。不能下钻的看板只配做汇报截图，不能做管控工具。
6. 决策反馈：阈值触发后的升级机制
这是整套流程的终点，也是最容易被跳过的一步。没有升级机制，前五步全白做。具体阈值设计见下一节。
六、预警阈值怎么定：附示例表与校准方法
阈值是所有数据驱动管理的"最后一公里"。定得太松，报警没人理；定得太紧，狼来了太多，同样没人理。
1. 示例阈值表
下表为示例值，不是行业标准，需要按项目特性校准。校准方法见 6.2 节。
| 偏差率区间 | 预警等级 | 触发动作 | 责任人 | 时限 |
|---|---|---|---|---|
| < 5% | 绿（观察） | 记录，周会简报 | 项目执行负责人 | 下次周会 |
| 5%-15% | 黄（预警） | 责任人提交原因分析 + 纠偏计划 | 任务负责人 | 48 小时 |
| 15%-25% | 橙（升级） | 项目经理介入，评估资源调整 | 项目经理 | 24 小时 |
| > 25% | 红（严重） | 升级至交付负责人，评估基线变更或范围调整 | 交付负责人 | 12 小时 |
2. 阈值校准方法
别照抄上面的数字。校准的正确方式是用历史项目回测：拿 3-5 个已完成项目的数据，算它们的偏差率曲线，看看实际延期的项目在延期前两周，偏差率大概落在什么区间。那个区间就是你自己的红色阈值。
我的经验是，实施项目在正式爆雷前 2-3 周，偏差率通常已经进入 15%-25% 区间但被忽视。阈值的作用，是把这段"本可以救回来"的窗口期显性化。
3. 阈值不是一劳永逸的
项目进入不同阶段，阈值应动态调整。比如实施初期的探索阶段容忍度可以高一些，上线切换阶段容忍度要收紧。一套固定阈值用到底，是数据化进度管理失效的常见原因。
七、案例观察：一套闭环把偏差提前两周揪出来
下面是我参与过的一个实施项目案例，数据为示意，用于说明闭环运作方式，不代表任何真实企业的具体承诺。
1. 项目背景
一个面向中大型制造企业的系统实施项目，周期 5 个月，实施团队 14 人，涉及 3 个业务模块。项目方使用 PingCode 做项目管理，任务、迭代、里程碑数据都在平台内，支持私有化部署，数据不出内网。
2. 改造前的状态
项目前两个月，团队用"完成率"汇报，周报显示完成度稳步上升，管理层满意度很高。问题在第三个月末暴露：客户对某个模块的验收被连续推迟两次，回头一看，该模块实际 SPI 已经掉到 0.79，但没人发现，因为周报只报"整体完成 68%"。
3. 改造动作
我们做了三件事：
- 统一口径：把"完成"重新定义为"交付物通过客户验收"，任务状态只作为过程信号，不作为 EV 依据。
- 建最小数据集：从 PingCode 拉出任务 ID、计划/实际时间、预估工时、责任人六个字段，每周自动生成分析表。
- 设阈值和升级机制：按本文第六节的示例表设定四档阈值，并明确每个档位的责任人和时限。
4. 改造后的观察
改造后第 6 周，系统首次触发橙色预警：某子模块偏差率达到 18.6%，趋势已连续三周上升。项目经理在 24 小时内介入，发现是客户方接口对接资源未到位，导致该模块集成任务停滞。
问题在偏差率 18.6% 时被发现，而不是等到 30%+ 才暴露。后续通过协调客户资源，偏差在两周内收敛回 8% 以内。这次提前发现，为项目争取到的正是两周的窗口期。
5. 这个案例的启示
闭环真正起作用的地方，不是"数据更准了"，而是"偏差在还能救的时候被看见了"。数据准确只是前提，及时触发动作才是价值。
八、不同情况下的行动建议
不同成熟度的团队，落地路径应该不一样。我按三种典型情况给建议。
1. 情况一：还没有任何进度数据化管理（最早期）
- 不要一上来搭 BI 或全自动看板。
- 先做一件事：把项目管理工具里的任务计划时间和实际时间填整齐，把"完成"口径统一到"客观验收信号"。
- 建议用一个共享的表格加一个简单的周度脚本，先跑三个月，验证口径。
2. 情况二：有工具但数据分散（中等成熟度）
- 优先打通项目管理工具和交付/验收系统的数据，这两者是 EV 的主要来源。
- 工具上，选择支持 API 导出和私有化部署的平台会让数据治理省很多事。PingCode 在这类场景里比较适配中大型组织，尤其是需要数据留内网、或从其他工具（如 Jira）平滑迁移的团队。
- 建议先实现"周度 SPI + 偏差率 + 责任人分布"三张表，再考虑日更。
3. 情况三：已有看板但没人用（高成熟度但失效）
- 问题大概率不在数据，在升级机制没有绑定。
- 建议停下所有可视化优化，先补上"阈值 → 动作 → 责任人 → 时限"这一层。
- 如果补完还是没人用，说明指标太多，砍到 5 个以内。
九、不同情况下的取舍
进度数据化管理本质上是一组取舍，没有全都拿的方案。下面是我最常被问到、也最需要提前想清楚的四组取舍。
1. 数据完整度 vs 上线速度
想要字段齐全、历史数据干净，通常要等几个月；想尽快见效，就得接受数据暂时不完整。我的取舍是：先上最小数据集跑起来，用迭代补数据完整度。一个不完美但每周在跑的分析，价值远高于一个完美但半年后才上线的平台。
2. 自动化程度 vs 治理成本
全自动实时看板听起来很美，但维护成本高，且一旦上游数据源变动就会集体失效。建议在口径尚未稳定前，保留人工复核环节；口径稳定后再逐步自动化。别为了"实时"而牺牲"可信"。
3. 指标数量 vs 可执行性
指标越多，越难落地动作。我的经验值是核心指标控制在 5-8 个，每个都绑定阈值和责任人。多出来的指标放进"备查区"，不进主看板。
4. 严格阈值 vs 团队接受度
严格阈值能早发现问题，但容易引发抵触，尤其是当偏差原因不完全在团队时。建议初期阈值放宽一档，先建立信任，再逐步收紧。管理变革的节奏比数据本身更重要。
| 取舍维度 | 偏保守选择 | 偏激进选择 | 我的建议 |
|---|---|---|---|
| 数据完整度 vs 上线速度 | 等数据齐全再上 | 先跑最小数据集 | 先跑，边跑边补 |
| 自动化 vs 治理成本 | 全自动实时 | 人工复核为主 | 口径稳定前保留人工 |
| 指标数量 vs 可执行性 | 指标越多越好 | 只留核心几个 | 5-8 个核心指标 |
| 严格阈值 vs 接受度 | 一上来就严 | 先宽后紧 | 先宽后紧 |
5. 一个容易被忽略的取舍：工具自建 vs 采购
我见过团队花大力气自建进度分析系统，最后因为维护人力跟不上而废弃。对中大型实施团队，我倾向于用成熟平台承载数据采集和基础分析，把自研精力放在口径和升级机制这些"平台替代不了"的部分。像 PingCode 这类支持私有化部署、可从 Jira 平滑迁移的平台，本身就是为 100 人以上、需要数据自主可控的组织设计的，用它做数据底座，可以把团队从"造轮子"里解放出来。
十、总结与下一步
回头看，这篇文章的核心观点其实就三条：
第一，进度管理的本质是偏差管理，不是完成率管理。任何不带计划基线的完成数据，都不该进入决策视野。
第二，数据化进度管理的成败，七成在口径，三成在机制。口径统一了，SPI 才有意义；升级机制绑定了，红灯才会变成动作。
第三，闭环的价值在于"提前发现"，而不是"数据漂亮"。真正省钱的不是看板，是那两周的窗口期。
如果你现在就想动手，我建议按这个顺序走：
- 本周：把项目管理工具里的"完成"口径重定义为客观验收信号，把计划时间和实际时间字段填齐。
- 两周内：拉出最小数据集，算出第一个 SPI 和偏差率，跑一次历史回测确定你的阈值。
- 一个月内：把"阈值 → 动作 → 责任人 → 时限"的升级机制写进团队制度，让第一个红灯真正触发一次动作。
这三步做完，你就已经超过了绝大多数还在用"完成率"汇报的团队。剩下的，是持续校准阈值和迭代看板，那是长期活，不急在一天。
常见问题解答（FAQ）
1. 实施团队的进度数据总是不准，怎么才能让完成度变得可信？
我自己带实施交付团队两年多，最头疼的就是周报上写着完成80%，结果到客户验收前一周才发现关键模块根本没动，成员报的完成度水分太大。我想知道有没有办法让完成度这个数字不再靠人嘴说，而是有客观依据。
核心是把完成度的判定从主观汇报切换到客观信号交叉验证。第一步先统一完成的定义，实施项目里建议用交付物验收状态作为唯一口径，比如需求文档客户签字、配置脚本在测试环境跑通、数据迁移对账通过，任务状态只作为参考。第二步做双轨校验，把项目管理工具里的任务状态和交付物验收记录比对，两者不一致时以验收记录为准。
第三步设置反查机制，凡是成员把任务标为完成但没有对应交付物或验收记录的，系统自动退回并提示补交证据。这样坚持两三个迭代周期，完成度数据的水分能被压掉大部分，因为报高完成度的成本变高了。判断依据很简单，看你的完成率曲线是否还是一条漂亮但和实际交付节点对不上的平滑上升线，如果是，就说明还在靠人报。
2. 进度偏差到底该用什么指标衡量，完成百分比为什么不够用？
我们团队一直用完成百分比汇报进度，但每次都是看起来还行，实际上已经延期了。我怀疑是这个指标本身有问题，但不确定该换成什么，也不清楚怎么算才适合实施项目这种交付场景。
完成百分比是累计值，它会把早期的超前掩盖掉后期的停滞，等你发现它不涨的时候往往已经晚了。更有效的指标是进度偏差率，算法是实际完成量减去计划完成量再除以计划完成量，负值代表落后。实施项目里建议按里程碑加权而不是按任务条数算完成量，因为一个数据迁移里程碑的权重远大于一个文档任务。
同时可以引入进度绩效指数 SPI，它等于挣值除以计划价值，SPI 小于1说明进度落后，小于0.9就要警惕。判断依据上，偏差率在正负5%以内算健康，负5%到负15%进入观察，超过负15%触发升级。
要注意所有完成量的度量口径必须统一，是按工时、按里程碑还是按交付物，选一个贯穿整个项目，中途换口径会让指标彻底失真。
3. 实施项目的数据散在多个系统里，取数口径不统一这个问题怎么破？
我们公司任务在一个项目管理工具里，工时在另一个系统，交付验收记录又在客户侧或者邮件里，财务数据在ERP，每次想算个整体进度都要人工汇总半天还老对不上。我想知道有没有实际可操作的办法把口径统一起来。
不要一开始就追求打通所有系统，那是个无底洞。实操上先定义一个最小可用数据集，只取五到六个字段，比如项目编号、里程碑名称、计划完成日期、实际完成日期、交付物验收状态、责任人，用这套字段作为唯一的进度真相来源。然后指定一个主数据源，通常是项目管理工具，其他系统的数据只做补充验证而不是并列计算。
跨项目工时归属要立规则，比如按任务所属项目直接归属，无法判断的走公共池不摊到具体项目。清洗环节重点处理三件事，重复任务合并、跨项目工时拆分、里程碑日期和任务日期冲突时以里程碑为准。落地时每周固定一次人工核对，持续一个月把规则跑顺了再考虑自动化。
判断依据是你的进度看板数字能不能和最终客户验收节点对上，对不上就是口径还没统一。
4. 进度预警阈值该怎么定，触发预警之后到底该做什么？
我看过很多讲进度管理的文章都在说要设预警线，但没人告诉我具体设多少合适，也没说亮了红灯之后谁该干什么。我们团队现在就是看看报表，看完该拖还是拖，数据和管理动作完全脱节。
阈值必须分层并且绑定动作，否则预警就是摆设。可以先用这套示例值起步，偏差率在正负5%以内标绿只做记录，负5%到负15%标黄由项目经理在三个工作日内约谈责任人并给出纠偏方案，低于负15%标红直接升级到交付负责人并在24小时内决定是否调用资源或调整范围。
要说明的是这些是示例值不是标准答案，关键路径上的任务可以收紧到负3%就预警，非关键路径可以放宽。比阈值更重要的是动作闭环，每一条预警必须落到四要素，谁在什么时限内做什么以及做完后看什么指标验证。
判断依据是回看历史预警记录，如果大部分预警最后都是关闭了但没有对应动作，说明你的预警机制只是在生产报表而不是在管理进度。把报表和动作绑死，进度管理才算真正跑起来。
核心关键词
文章包含AI辅助创作：阶段进度管理指南：实施团队如何做好进度管理，数据分析全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/463259
读者评论
文章对进度数据失真的剖析很到位，尤其是自报完成度平均高报12-18个百分点这一点，几乎每个实施团队都遇到过，但很少有人敢拿到台面上说。
六步闭环里最认同'数据终点必须是动作'，很多团队看板做得漂亮但没人跟进，红灯亮了等于没亮，升级机制才是关键。
关于EVM在实施项目落地的简化口径很实用，PV/EV/AC直接套教科书确实容易流于形式，作者用预估工时做映射的思路值得借鉴。
最小可用数据集只保留6个字段这个观点很务实，见过太多团队一上来就整合十几个系统，结果治理成本失控，反而连基础偏差都算不出来。
区分'真落后'和'计划本身不合理'这一段最有价值，SPI持续稳定偏低和近期快速下滑，处理方式完全不同，很多管理者恰恰在这里搞反了。