2. PMIS驾驶舱的数据底座

PMIS驾驶舱之所以能在一屏之内回答“项目现在怎么样、哪里会出问题、下一步该盯谁”，靠的不是仪表盘本身，而是它背后那套被严格建模、持续校验的核心数据对象。驾驶舱只是“读数据的人”，真正决定读数是否可信的，是项目主数据、WBS、任务、资源、日历和依赖关系这六类对象的结构与质量。本节按“对象是什么—怎么建模—质量怎么卡”的顺序展开，并给出可直接对照的建模与校验要点。

一、六类核心数据对象及其建模定位

这六类对象不是并列的表格，而是一棵有依赖关系的“数据树”：项目主数据是根，WBS 是骨架，任务是叶子，资源与日历是约束条件，依赖关系是连接枝干的边。任何一层建模错误，都会沿着这棵树向上污染驾驶舱指标。

二、项目主数据：驾驶舱的“根节点”

项目主数据是驾驶舱筛选和聚合的第一维度。建模时至少要固化以下字段：项目编码（全局唯一，建议采用“公司码-年份-流水号”如 PM-2025-0137）、项目名称、项目状态（未启动/进行中/暂停/已关闭）、计划开始与计划完成日期、项目经理、所属组织、项目类型。其中“项目状态”直接决定驾驶舱是否将该项目的进度数据纳入统计——已关闭项目若仍处于“进行中”，会持续拉低整体完成率。

质量要求有三条：一是编码唯一且不可复用，项目关闭后编码冻结；二是状态变更必须留痕，任何状态跳变都要记录操作人与时间；三是计划日期一旦被基线锁定，修改必须走变更流程，否则驾驶舱的“计划完成率”会随口径漂移。

三、WBS：进度聚合的骨架

WBS 决定了驾驶舱能从哪几个层级下钻。推荐采用“层级码 + 父节点 + 交付物”的建模方式，层级码用点分十进制，例如 1.2.3 表示第 1 层第 2 个节点下的第 3 个子节点。父节点字段用于构建树形结构，交付物字段用于回答“这个节点到底要交出什么”。

关键质量规则是“叶子节点才挂任务”。如果 WBS 的非叶子节点上直接挂了任务，驾驶舱在按 WBS 汇总进度时会出现重复计算。校验方法很简单：对每个 WBS 节点统计其直接关联的任务数，若某节点既有子节点又有任务，即判定为违规。此外，WBS 编码必须与父节点编码保持前缀一致，例如父节点为 1.2，子节点只能是 1.2.x，不能出现 1.3.x 挂在 1.2 下。

四、任务：驾驶舱最细粒度的进度信号

任务是驾驶舱里数量最多、变化最频繁的对象。建模字段包括：任务编码、所属 WBS 节点、任务名称、计划开始、计划完成、实际开始、实际完成、工期、完成率、负责人、前置任务。其中“工期”与“计划开始/完成”必须满足一致性：若采用日历日，则 计划完成 = 计划开始 + 工期 - 1；若采用工作日，则需扣除日历中的非工作日。

完成率的建模要特别小心。建议统一采用“按工期加权”而非“按任务条数平均”，否则一个 1 天的小任务和一个 30 天的大任务对父节点进度的贡献会相同，驾驶舱读数会严重失真。示例：某 WBS 节点下有 A、B 两个任务，A 工期 2 天完成 100%，B 工期 8 天完成 50%，则节点完成率 = (2×100% + 8×50%) / (2+8) = 60%，而不是 (100%+50%)/2 = 75%。

五、资源与日历：约束条件的建模

资源对象用于回答“谁来做、做多少”。建模时区分“资源类型”（人力/设备/材料）与“具体资源实例”，并记录可用量、单位成本、所属组织。任务与资源之间通过“分配关系”连接，分配记录中必须包含投入百分比或工时数。驾驶舱的资源负荷指标就是按“任务工期 × 投入百分比”逐日累加得到的。

日历对象常被忽视，但它直接决定工期计算。至少需要三类日历：项目日历（全局工作日）、资源日历（某人的休假与班次）、任务日历（特殊任务的作业窗口）。当三者冲突时，以任务日历优先、资源日历次之、项目日历兜底。若日历缺失，系统只能按自然日计算，会把周末和节假日算进工期，导致驾驶舱显示的“剩余天数”偏小。

六、依赖关系：关键路径的边

依赖关系是驾驶舱识别关键路径和预警连锁延期的依据。建模时需明确四种类型：完成-开始（FS）、开始-开始（SS）、完成-完成（FF）、开始-完成（SF），并记录滞后量（Lag）与提前量（Lead）。最常用的是 FS，即前置任务完成后后续任务才能开始。

质量红线是“依赖无环”。一旦出现 A 依赖 B、B 依赖 C、C 又依赖 A 的循环，关键路径算法会陷入死循环或给出错误结果。校验方法是对依赖图做拓扑排序，若无法输出全部节点，即存在环。此外，跨项目依赖必须显式标注来源项目编码，否则驾驶舱在单项目视图下会丢失外部约束。