2. 计划与实际的基准建模

偏差分析之所以经常“算不准”，往往不是公式问题，而是基准本身没有建好。计划侧和实际侧如果不在同一套结构、同一套口径、同一套时间轴上，任何偏差数字都只是巧合。本节要解决的核心问题是：如何把“计划”和“实际”建成两条可比较、可追溯、可复算的基准线。

一、计划基线：不是一张表，而是一组受控快照

计划基线（Baseline）是经过批准、冻结、用于对比的计划版本。它至少包含四个要素：范围基线（做什么、不做什么）、进度基线（何时做、逻辑关系）、成本基线（预算多少、如何分摊）、资源基线（谁来做、投入多少）。四者缺一，偏差分析就会出现“进度提前但成本超支却无法解释”的盲区。

建立基线时，关键动作是冻结而非“保存”。冻结意味着：该版本被赋予唯一编号（如 BL-001），记录批准人、批准日期、生效范围；后续任何修改不得直接覆盖，只能通过变更单生成新版本。例如某项目在 3 月 1 日批准 BL-001，4 月因客户新增需求批准 BL-002，则 3 月执行数据对比 BL-001，4 月之后对比 BL-002，历史对比结果不因新版本而改变。

二、实际执行数据：来源、时点与可信度分层

实际数据不是“把现场数字填进来”这么简单。它有三个必须明确的属性：来源系统（如工时系统、采购系统、进度填报系统）、数据时点（截止到哪一天、是否含未过账数据）、可信度等级（已确认、待确认、估算）。

以工时为例：现场班组每日填报 8 小时，但其中 2 小时属于待确认的加班，若直接计入实际成本，会导致当期偏差虚高。合理做法是分层记录：

实际工时记录示例（2024-06-15 截止）
任务编号  计划工时  已确认工时  待确认工时  数据来源
T-101     120       96          8           工时系统
T-102     80        80          0           工时系统
T-103     200       150         20          现场填报（估算）

对比时，应优先使用“已确认”数据；若必须使用估算值，需在偏差报告中标注数据成熟度，避免把估算误差误判为执行偏差。

三、时间粒度：计划与实际的“最小可比单元”

时间粒度决定了偏差能被观察到的最小周期。计划按月编制、实际按周填报，直接相减就会产生“月内波动被平均掉”的失真。对齐原则是：实际数据的粒度必须细于或等于计划粒度，再向上汇总到计划粒度进行对比。

例如计划按月度里程碑控制，实际按周填报，则每周实际完成后先汇总为月度实际，再与月度计划对比。若实际粒度粗于计划（如计划按周、实际按月），则只能做月度对比，周级偏差不可见，此时应在报告中声明“周级偏差不可观测”。

四、口径对齐：让“同一件事”在两侧可相减

口径对齐是基准建模中最容易被忽视、也最容易导致偏差失真的环节。需要对齐的典型口径包括：

• 范围口径：计划含设计变更，实际是否含？未含则需剔除或补录。
• 计量单位：计划用“人天”，实际用“工时”，需统一换算系数。
• 成本口径：计划是否含税、含管理费分摊，实际是否同口径。
• 完成定义：计划“完成”指开工、完工还是验收？实际填报是否同一标准。

实操中建议建立一张口径对照表，逐项写明计划侧定义、实际侧定义、换算规则和责任人。任何一侧口径变更，必须同步更新对照表并触发基线版本评审。

五、版本管理：让每一次对比都可复现

版本管理要回答三个问题：当前对比的是哪个计划版本？实际数据截止到哪个时点？两者是否属于同一口径？ 推荐采用“基线编号 + 数据截止日 + 口径版本”三元组标识每一次偏差计算。例如：

偏差计算标识：BL-002 / 2024-06-30 / CAL-03
含义：对比计划基线 BL-002，实际数据截止 2024-06-30，
      使用第 3 版口径对照表。

这样，任何一次偏差结果都可以被复算和追溯。若后续口径调整，只需生成 CAL-04，历史结果仍保留 CAL-03 的原始结论。

六、一个可落地的基准建模检查清单

在实际项目中，可按以下顺序完成基准建模，避免遗漏：

基准建模完成后，偏差分析才真正具备工程意义：计划侧有受控基线，实际侧有分层数据，两侧通过口径对照表和时间粒度规则对齐，每一次计算都有唯一标识。这样得到的偏差，才是可解释、可追溯、可行动的偏差。