资源迁移：从 Microsoft Project 迁移容量规划

对于把 Project Server 用好的 PMO 来说，它的价值很少在于项目计划本身，而在于其下的运营层：每个项目都从中取用的统一组织资源池、为开票和收入确认提供数据的带成本工时表、自动传播的日历例外，以及资源经理每周据以真实数据决定人员安排的跨项目视图。利害所在正是这个运营层。计划可以迁移。运营层却常常迁移不过去。

每当 PMO 低估这一点，三种失败模式就会反复出现：

• “资源以后再加”的陷阱。团队干净地迁移了计划，把资源池推到下一个冲刺。等到那时，各项目负责人已经在自己的项目里建了重复的资源，资源经理也失去了让跨项目容量视图得以运作的唯一事实来源。
• “成本费率对上线不关键”的陷阱。标准费率被推迟到第 2 阶段的清理中。两个月后，财务发现月结需要的带成本工时表数据在新平台上已不存在，因为记录工时时费率还没有加载。这些数据无法事后重建；收入确认就此停摆。
• “Planner Premium 就够了”的陷阱。PMO 想当然地认为 Microsoft 的云产品覆盖同样的用例。在资源建模方面，它并不覆盖。Planner Premium 没有组织资源池，没有带成本的工时表，也没有跨项目的资源视图。迁移之后才发现就太晚了。

这三者的结构性原因是：资源模型是 Project Server 中在快速产品演示里最不显眼、在供应商对比清单里覆盖最少的部分。计划、甘特图和仪表板在演示中很好看。组织资源池则不然。因此买家在选择平台时很少看重资源模型的覆盖，直到在生产中才发现缺口。本指南先介绍模型，再介绍迁移战术，前提是最重要的决定是你选择哪个目标平台。

在决定迁移什么之前，先盘点你拥有什么。Project Server 的资源模型有六个层级，每一层的迁移方式都不同：

不是每个 PMO 都用到所有层级。盘点时该问的是：“我们的团队做决定时真正依赖其中哪些？”如果不用带成本的工时表，费率表这一层就只是摆设，去掉也无妨。如果不用通用资源为需求建模，可以把它们合并掉。如果确实用来建模，那么这项能力在目标平台上就没有商量余地。

先盘点，再比较平台。盘点的结果是一份目标平台必备能力清单，这份清单决定了迁移其余部分的走向。下一节假定你已经有了这份清单。

按资源模型覆盖情况筛选后，平台对比的范围就会缩小。下面是诚实的全貌，按上面的六个层级排列。每一项为是、部分或否：

Microsoft 的云产品（Planner Premium / Project for the Web，同一个产品的不同 SKU 名称）几乎把整个资源模型都排除在外。这是刻意的定位选择：它是带一层项目功能的团队任务工具，而不是 PMO 平台。认真使用 Project Server 资源模型的 PMO，无法在不损失重要能力的情况下用 Planner Premium 取代它。

Smartsheet 的 Resource Management 模块和 Workfront 都保留了组织资源池的概念。它们在细节上不同：Smartsheet RM 是单独的 SKU，每个席位会增加不小的费用；Workfront 的资源池很扎实，但每席位价格是四者中最高的。Onplana 没有单独的资源池：每个人都是组织成员，其资源模型是该人员在所有项目中的每周容量（Professional 方案及以上）、三个层级的费率（人员、角色、组织默认值），以及带具名例外的工作日历，没有付费附加组件。它没有通用资源、按人员的日历或正式的 RBS。价格起步为每席位每月 12 美元（Professional）。与 Planner Premium 的诚实对比见我们的 Planner 对比页面。

还有一个难以放进表格的维度：即使基本功能存在，跨项目容量视图的质量在各平台之间差别也很大。有的只显示直接分配到任务的工时；有的包含子项目的汇总；有的包含通用占位的分配。如果你的资源经理每周用这个视图决定人员安排，请在评估时用分配工时最多的 25 个资源并排比较。

在导出任何内容之前，对资源模型做一次完整盘点。这与项目清单的盘点不同：那份清单编录项目；这份清单编录其下的资源层。成果是一份资源迁移准备报告，列出每个资源要素、它现在在哪里、要去哪里，以及由谁负责迁移。

1. 带属性的资源列表。导出整个组织资源池，包括名称、类型（具名/通用/成本）、邮箱（具名资源）、最大单位、标准费率、角色/资格以及 RBS 路径。OData 端点 /Resources 是权威来源；Reporting Database 有更多派生字段，但只存在于本地部署的 Project Server 中。
2. 成本费率表。Microsoft Project 支持每个资源最多 5 个成本费率（费率 A 到费率 E），带生效日期区间。导出每个费率层级和每一行生效日期。如果你的 PMO 只用费率 A，可以忽略 B–E，但在想当然之前先确认确实如此。
3. 日历例外。为每个资源导出具名日历例外的列表，包括名称、日期区间和修改后的工作时间。如果目标平台不保留具名例外，请把名称存到一个配套的 CSV 中，让原因（“会议周”“假期停工”）得以保留。
4. RBS 层级。导出资源分解结构：每个节点、父子关系以及分配到每个节点的资源。正是这个层级让资源经理能按自己的汇报结构筛选容量视图。
5. 活动的工作分配。为每个活动项目中的每个活动工作分配做快照：哪个资源、哪个项目、哪项任务、分配工时、实际工时、计划开始和完成。这是校验的基础；迁移后你要比较源系统和目标平台中的分配。
6. 资源自定义字段。如果你的 PMO 在资源上定义了 Enterprise Custom Fields（安全许可级别、可计费标记、合同类型），请与资源列表一起导出。有的目标平台会把它们建模为内置字段，有的建模为自定义字段，有的则不支持；这决定了后续的字段映射。

完成的准备报告是迁移其余部分的基础。要在投入之前检查导出质量，可以把一个示例资源池放进迁移预览工具：上传资源池中有代表性的一部分，确切看到哪些字段、费率和例外能干净地迁移过去。

五个阶段，每个阶段都有一项成果和一个决定是否继续的检查点。对于 100–250 个资源的资源池，总时间通常为 3–5 周；如果成本费率表高度定制或 RBS 很大，还需要更久。

阶段 1：盘点和决策（1 周）

完成上面描述的预先盘点，然后根据资源模型中哪些层级对你的团队没有商量余地来决定平台。把决定连同理由一起记录下来；当有人问起为什么所选平台没有功能 X 时，你会重读这一节。

• 在使用中的租户上进行盘点
• 对照你的必备层级清单评估每个目标平台
• 选定目标平台并记录理由
• 获得 PMO 管理层对所选平台的批准

检查点：准备报告已签字；目标平台已选定。

阶段 2：导出资源池（2–3 天）

趁 Project Server 仍在运行时导出，然后确认导出包含清单中的每个层级。不要依赖 .mpp 文件的导出来获取资源池；它们只包含项目本地资源的分配，而不是带费率、日历和 RBS 的组织资源池。

• 资源列表，来自 /Resources
• 日历例外，来自 /Resources/Calendars
• 成本费率表（或本地部署的 Reporting DB）
• RBS，来自 SOAP API 的端点，它们在 OData 中没有对应项
• 活动的工作分配，来自 /Assignments
• 与准备报告一致的计数

检查点：每个层级的导出计数都与准备报告一致。

阶段 3：在目标平台重建（3–7 天）

把资源池导入目标平台，并逐层解决平台对比中发现的迁移缺口。无法迁移的通用资源重建为具名占位。无法迁移的日历例外名称存档。资源自定义字段映射到目标平台的内置字段或自定义字段定义。

• 导入资源列表（批量导入或目标平台的 API）
• 重建 RBS 层级，并把资源分配到各自的节点
• 在加载任何工作分配之前，先加载标准费率和成本费率表
• 按资源应用日历例外
• 按平台的模型迁移通用资源
• 映射资源自定义字段

检查点：资源池计数、RBS 层级和费率表计数与源系统一致。

阶段 4：分配并校验（1 周）

逐个项目迁移任务分配，按负责团队分批进行。每批完成后，接收团队在 48 小时内针对自己的项目对照源系统校验目标平台中的分配。在这一批确认干净之前不要继续；在许多项目上追查累积的分配偏差，比逐个项目纠正要难得多。

• 分批迁移工作分配，每批 10–25 个项目
• 按资源和项目比较分配：源系统与目标平台
• 调查任何 > 5% 的偏差
• 在过去工时表的样本上核对带成本工时表的计算

检查点：所有项目中每个资源的分配差异 < 5%。

阶段 5：容量视图和核对（1 周）

重建资源经理真正在用的容量视图，并与 Project Server 并行运行至少 5 个工作日。每日差异报告会标出新平台的容量计算与旧平台不同的每一处。调查每一处差异。把真实存在的差异记录为已知限制。

• 在目标平台重建最主要的 5 个容量视图
• 为分配工时最多的 25 个资源生成每日差异报告
• 调查 > 5% 的偏差；记录平台之间的真实差异
• 培训资源经理使用新的容量视图界面
• 切换：目标平台成为事实来源，Project Server 转为只读

检查点：连续 5 个工作日的每日差异报告干净；资源经理认可新的容量视图界面。

最常出现的五种资源模型失败模式，以及各自的预防方法：

这五种错误的共同模式：每一种都是“以后再说”的决定，当下代价很小，到了生产中代价很大。核对工作是初始预算中最常被低估的成本之一；在迁移成本计算器中，它归入并行运行。

校验阶段包括三项检查，每一项都产出一份证据。把它们与准备报告一起存档；合在一起就是迁移的审计线索。

1. 按资源核对分配。对未来 90 天内分配工时最多的 25 个资源，比较源系统和目标平台中的分配。容差：±5%。偏差更大，说明工作分配迁移丢失了数据，或目标平台的容量计算在结构上不同于 Project Server。两种情况都要调查。证据：按资源的差异报告。
2. 核对带成本工时表的样本。从 5 个不同资源中选出最近关闭的 10 份工时表。在目标平台中用相同的时间条目重新计算成本。容差：±1%（这是钱；容差比分配的更严）。偏差 > 1% 说明费率有误、丢失了日历例外，或两者都有。证据：并排的成本计算。
3. 跨项目容量视图的一致性。重现资源经理最常用的 3 个容量视图。与 Project Server 同一时段的最后一次运行进行比较。两个视图以不同方式归类分配（直接或子项目、具名或通用）是正常的。把这些记录为迁移后手册中已知的平台差异。证据：并排截图，附已记录的差异。

校验阶段的成果是一份迁移结果报告，列出已迁移的、未迁移的以及仍未解决的内容。它与第 1 阶段的准备报告一起，构成完整的审计线索。

PMO 负责迁移手册，但资源模型带来的后果，如果没人提前提出，财务团队会在切换后才发现。每次涉及带成本资源的迁移都会出现三种模式，每一种造成的影响都不同于 PMO 一侧的问题。

容易混淆的三种费率概念

Project Server 为每个资源管理三种听起来相似、但不能互换的费率：标准费率（用于为分配建模的内部每小时成本，常为劳动力的完全成本）、成本费率（用于计算工时表会计成本的费率，有时按不同的工作类型分成 A 到 E 的费率表）和开票费率（为某个合约的可计费工时向客户收取的费率）。有的 PMO 三种概念只用一个费率；有的每种概念各用一个费率；还有的在每种概念内部再分费率表层级。

导出之前，问清楚财务实际使用哪些费率概念、哪些费率表层级对应哪些工作，以及每个费率为目标平台的哪些字段提供数据。导出是每个资源每个费率一行；导入则是一个映射决定，决定下个季度的收入确认报告能否对得上。一个常见且可以挽回的错误，是把开票费率加载到成本费率字段中。带成本的工时表于是按开票费率计算，结果报告显示成本虚高，解决办法是重新导出并再加载一次。更糟且更难纠正的错误，是把成本费率加载到开票费率字段中。按错误费率开出的发票必须重开，与客户的纠正沟通也不是免费的。

资本化规则不会自动迁移

受监管或投资密集型组织的 PMO 通常有劳动力资本化政策，规定“可资本化项目上的工程工时计入资产负债表上的资产，而不是费用”。在 Project Server 中，这些规则通常以基于 OData 数据源构建的视图或报告存在，有时带有项目级和任务级的标记。这些基础设施没有一样会自动迁移。标记可以导出（自定义字段的值）；视图和报告则不能。财务必须在新平台上基于同样标记过的数据从头重建资本化报告。

风险在于一个悄无声息的季度：资本化报告没有重建，本该资本化的工时进了费用，这个期间带着错误的数字结账。这里的重大错误就是一项内部控制发现。请财务把重建资本化作为与迁移并行的一条工作线，而不是后续工作，并把切换的前提定为至少一个已结账期间的并排资本化报告能对得上。

可计费利用率报告需要明确配置

专业服务类 PMO 靠可计费利用率（可计费工时除以有薪工时，按资源和总计）过日子。Project Server 通过把工时表数据与工作分配或任务上的“可计费”标记结合起来得出它。标记能干净地导出；报告则不能。如上面的对比矩阵所示，对原生可计费利用率报告的支持因目标平台而异。Onplana、Smartsheet RM 和 Workfront 把这份报告作为一等功能提供；Microsoft 的 Planner Premium 没有可计费的概念。

对于迁移到支持可计费利用率的平台的 PMO，把切换的前提定为最近 4 周的并排报告在 ±2% 以内对得上。任何更大的偏差都说明费率映射有误、缺少可计费标记，或有工作分配没有迁移。对于目标平台不原生支持可计费利用率的 PMO，计划把 OData 快照导入下游的 BI 工具（Power BI、Looker、Sigma），并在那里重建报告。无论哪种情况，财务都应该在关闭旧平台之前认可报告的准确性。否则，新平台上的第一次月结就是缺口暴露的时候，而那是最糟糕的时机。

为什么财务必须在切换前参与

在每一次财务参与得晚的迁移中，同样的三个问题都会重演：费率映射必须重做，因为财务不认同 PMO 对哪个费率是哪个的理解；资本化报告没有重建，新平台上的第一次季度结账错误地报告了资本化的工时；可计费利用率的偏差超出了 PMO 的容差，因为财务采用的规则不同。这些都不是平台问题；全都是协调失误。解决办法代价很小：在第 1 阶段（盘点）和第 4 阶段（分配并校验）把财务列为指定审批人。他们的批准就把费率映射、资本化报告和可计费利用率容差这几件事闭环了。没有这一步，PMO 交付了迁移，财务却在几周后才发现代价，几乎总是在月结期间，几乎从来没有从容重做的时间。

迁移只是起点；长期的问题是你的 PMO 的容量规划实践能否在新平台上继续运作。四个习惯把保持纪律的团队与半途走样的团队区分开来：

• 强制执行唯一事实来源。组织资源池是权威来源；在项目中创建本地资源是走样的早期信号。有的平台允许按项目锁定创建权限。如果可用就用上；否则，每周做一次评审，把每个项目的资源列表与组织资源池对比。
• 每季度评审费率。12+ 个月未评审的标准费率会偏离劳动力的真实完全成本。带成本的工时表随之偏离财务现实。定下每季度的节奏来评审并更新费率表。
• 对具名例外保持纪律。日历例外会悄悄累积。一个资源在 3 年里有 30 个具名例外是正常的；没有评审节奏，例外就会僵化。每年评审一次每个资源的例外数量，删除超出政策规定保留期的所有内容。
• RBS 的演进。迁移时正确的汇报层级，会随着组织调整而过时。在组织架构的整体评审周期内，每 6 个月安排一次 RBS 评审，让容量视图的划分始终有意义。

PMO 关于资源模型迁移最常问的问题。完整的 FAQPage 结构化数据在本文的结构化数据中，以便这些问题出现在 Google 的“相关问题”功能里。

放大