华为PMOP框架深度拆解：BTMS年度规划与DCP决策评审点全解析

简介：这份PPT资料聚焦华为变革引擎PMOP框架，系统讲解其如何驱动战略级项目管理与业务创新，面向企业变革管理者、PMO从业者及项目管理学习者。内容围绕BTMS V2.0业务变革管理体系展开，涵盖年度规划流程、解决方案开发PMOP流程、需求管理、变革使能、管控团队与架构管控等模块，并详解DCP决策评审点、TR技术评审、流程裁剪原则及架构基础管理等优化要点，帮助读者理解从变革战略规划到项目执行、生命周期管理的端到端集成框架。资源包共1个pptx文件，约2.18MB，以图文并茂的幻灯片形式呈现，结构清晰，便于按章节查阅与培训引用。目前已有113人学习，适合需要搭建变革管理体系、梳理PMOP流程或准备相关内训材料的中高级读者参考借鉴。

1. 从一份 111 页 PPT 说起：华为 PMOP 框架到底解决什么问题

很多做项目管理的同行，第一次听到 PMOP 这个词，是在华为内部流程文档或者变革管理相关的资料里。它不是一个孤立的工具，而是嵌在 BTMS（Business Transformation Management System，业务变革管理体系）里的一条核心流程链。这份 111 页的 PPT 把 BTMS V2.0 的整体框架、年度规划流程、解决方案开发流程、需求管理、变革使能、管控团队、架构管控这些模块全部串了一遍，信息密度相当高。

它解决的核心问题是：一家公司每年有几十甚至上百个变革项目在跑，怎么保证这些项目不是各自为战，而是真正对准业务战略、有优先级、有预算约束、有架构约束、有决策评审点？PMOP 就是这套“从战略到落地”的引擎。适合谁看？做企业级 PMO、变革管理、流程 IT 规划、架构管控的从业者，以及想理解华为怎么把项目管理做成一套可复制体系的人。这不是教你考 PMP 的教材，而是一套大公司真实在跑的运作框架。

2. BTMS 框架拆解：年度规划流程的七个阶段与决策控制点

2.1 BTMS 的整体结构：规划、执行、使能三条线

BTMS 框架可以理解为三层：最上面是业务变革规划，中间是举措（Initiative）管理，下面是解决方案开发与运作管理。这三层不是割裂的，而是通过决策控制点（DCP）和技术评审点（TR）串起来的。

年度规划流程负责回答“明年做什么、为什么做、花多少钱、优先级怎么排”。解决方案开发流程（也就是 PMOP 流程）负责回答“怎么做、分几个阶段、每个阶段谁拍板”。变革使能则是横向支撑，包括管控团队、规则管理、架构管控、业务绩效管理。这三条线合在一起，才构成一个完整的变革管理体系。

PPT 里特别标注了红色高亮部分为 BTMS V2.0 的范围，说明 V2.0 相比之前版本做了裁剪优化、增加了 TR 评审、强化了架构管控。这些优化点后面会展开讲。

2.2 年度规划的七个阶段：从启动到汇报签发

年度规划流程在 PPT 里被拆成了七个阶段，每个阶段都有明确的阶段目标、输入、输出、主要活动、本阶段要求和决策控制点。这套结构非常值得借鉴，因为它把“规划”这个容易变成拍脑袋的事情，拆成了可管理、可评审的步骤。

第一阶段：变革年度规划启动。阶段目标是组建公司整体规划团队和各领域规划团队，发布任命并正式启动，制定工作计划。输入是公司业务 SP 计划，输出是变革规划组任命、变革规划工作思路、变革规划工作计划。主要活动包括确定规划团队的组织结构、人员名单和角色职责，明确本年度变革规划过程和方法，制订工作计划。这个阶段的要求里有一条很关键：GPO 参与、业务参与、架构牵引、一线参与。也就是说，规划不是规划部门关起门来写文档，而是业务、架构、一线都要派人进来。

第二阶段：需求收集和现状分析。阶段目标是获取和识别关键业务需求或业务问题，基于这些识别出关键变革需求。输入是业务需求、业务痛点、客户反馈的问题，输出是变革需求。主要活动是通过访谈、workshop、现场调研等方式收集需求和痛点，通过高层访谈或参与业务规划讨论会获取业务重点，然后对需求和痛点进行整合分析。这里 PPT 特别提到“防止多方收集给一线带来重复工作”，要求在一线规划组统一协调组织下进行。这个坑很多公司都踩过：各个部门分别去问一线，一线被问烦了，数据质量反而下降。

第三阶段：上年度变革总结和确定下年度变革重点。这个阶段要收集上年度业务 KPI、重点项目完成情况、主要变革工作进展，然后明确年度变革重点并达成共识。输入包括变革需求、业务 SP 规划和年度业务规划、业务重点、变革战略规划输出的变革战略/变革重点/变革路标、上年度重点变革项目、企业架构、业界领先实践。输出是上年度变革总结报告、下年度变革重点、专题清单。主要活动包括收集上年度变革项目完成情况、变革关键指标达成情况、变革关注的主要问题及关键措施执行情况、流程对业务的支撑状况、变革工作的经验和教训。然后对识别出的关键变革需求进行分析和优先级排序，对外部环境进行分析并识别对业务的影响，理解公司业务 SP&BP 规划确定的业务重点，分解和匹配各领域变革重点。这里有一个关键动作：从变革重点清单中识别出还没有明确流程&IT 如何支撑的重点，形成变革专题，指定责任人。这就是专题规划的来源。

第四阶段：专题规划。阶段目标是以“专题规划”的形式进一步明确变革重点如何通过流程 IT 变革实现。注意 PPT 里有一句说明：并不是所有变革重点都需要经过专题规划阶段而识别出变革举措及变革项目清单，对于比较清晰的变革重点，可以结合变革需求直接规划出变革举措和项目清单。输入是变革重点、变革需求、专题清单、企业架构、业界领先实践，输出是专题规划报告。主要活动是针对专题所涵盖的变革需求进行深入分析，给出解决方案及路标，架构方案设计主要活动包括 BA/AA/IA/TA。本阶段要求架构牵引和协同。决策控制点是单个专题由架构支撑组或 RMT 进行评审，全部专题拉通评审由 EAC/SAG 技术评审点负责。

第五阶段：确定变革举措及项目长清单。这个阶段把变革重点转换为变革举措（Initiative）或变革项目，输出举措清单、项目长清单。PPT 里对“变革举措”有一个明确定义：由一个或多个相关联的变革项目组成，这些项目都瞄准同一业务目标的达成。推行变革举措的目的是明确项目是瞄准某一业务目标而开展的，便于跟踪和管理相关联的项目，以更好支撑业务目标的达成，也便于项目的分层分级管理。主要活动包括识别变革举措、对举措进行描述、识别具体项目、编写项目 PI 初稿、进行变革重点与举措/项目的匹配、协同要求。本阶段要求 GPO/业务部门参与，GPO 代表及业务代表要参与变革举措和项目 PI 的编写。决策控制点是领域层变革举措清单、项目长清单向 Sub-3T 汇报，公司整体变革举措清单、项目长清单向 C-3T 汇报。

第六阶段：进行 ROI、项目/举措关联分析。阶段目标是进行项目 ROI 分析和项目优先级排序，明确进行举措/项目关联关系分析。输入是变革举措清单、项目长清单、项目 PI 初稿，输出是项目 ROI、举措/项目关联关系结果、举措及项目排序结果、更新的项目 PI。主要活动包括 ROI 分析、举措/项目关联关系分析（从范围、方案、进度、试点/推行等多个方面识别分析关联关系，给出建议解决措施及责任人）、项目优先级排序（根据 ROI 评估结果对项目进行排序，四象限）。这个阶段没有技术评审点和决策控制点，但输出直接决定下一阶段的预算分配。

第七阶段：确定变革投资预算及举措/项目短清单。阶段目标是根据 ROI 分析及排序以及项目资源平衡的结果，给出年度变革举措/项目短清单的建议，根据项目短清单确定变革年度投资预算。输入是变革举措清单、项目长清单、项目 PI、项目 ROI、项目优先级排序结果、举措/项目关联关系结果，输出是变革举措清单、项目短清单、变革预算。主要活动分领域和公司整体两条线：各领域根据 ROI 分析及排序结果给出领域年度变革举措/项目短清单建议，确定领域变革年度投资预算，从汇总表中按月汇总领域项目的资源需求；公司整体根据跨领域项目 ROI 分析及排序结果给出跨领域年度变革举措/项目短清单建议，集成各领域项目短清单形成公司整体变革举措/项目短清单，形成公司总体预算，汇总所有项目对资源的需求。本阶段要求里有一条很实操的经验：资源平衡。在确定公司整体变革对资源（特别是 IT 资源）的需求时，如果某一月份的需求峰值超过了当月可提供的资源，则建议进行需求平衡，将部分项目的启动时间进行调整，避开该峰值。这就是为什么很多公司的项目排期看起来“错峰”，背后其实是资源约束在起作用。

第八阶段：输出年度规划报告并汇报签发。阶段目标是年度规划报告得到各相应 GPO 认可，最终由 RSC 批准签发。输入是年度规划前期所有输出，输出是领域《年度规划报告》和公司《年度规划报告》。主要活动是各领域整合年度规划前期成果形成《年度规划报告》并向 GPO 汇报，整合成公司《年度规划报告》向 RSC 汇报和各利益关系人沟通获得认同。决策控制点是领域变革规划报告向 Sub-3T 汇报并得到 GPO 认可，公司整体变革规划报告向 C-3T 汇报，最终向 RSC 汇报并由 RSC 批准签发。

把这七个阶段连起来看，你会发现它本质上是一个从战略输入到预算分配再到高层签发的漏斗。每一步都有明确的输入输出和责任人，不是靠开会拍脑袋。这套流程如果能在公司里跑通，年度规划的质量会有质的提升。

3. PMOP 解决方案开发流程：DCP 决策评审点与 TR 技术评审点怎么配合

3.1 PMOP 流程的六个阶段与两类评审点

PMOP 流程是 BTMS 框架里负责“解决方案开发”的部分，关注的是方案设计与实施端到端流程。PPT 里给出的阶段划分是：概念、计划、开发、验证/试点、推行，加上前期的 Charter 开发和后期的生命周期管理。每个阶段之间有 DCP（Decision Check Point，决策评审点）和 TR（Technical Review，技术评审点）。

DCP 包括 Charter Review、CDCP、SDCP、PDCP、PRR、DRR。TR 包括可行性 TR、概要设计 TR、准入 TR。PPT 里明确说，PMOP 流程中的 DCP 保证了项目各阶段的关键要素被执行。这句话看起来简单，但实际落地时很多公司只做了 DCP 的形式，没有真正把决策要素落实。

BTMS V2.0 的优化点之一是增加 TR 评审，对项目方案、架构和关联关系进行技术评审。优化点之二是优化 DCP 决策要素和决策机制，明确 PMOP 各阶段明细活动，增加架构/协同/一线参与/GPO 参与等管控要求。优化点之三是针对项目的不同特点和复杂程度，对 PMOP 流程设置灵活的裁剪原则，保证大小项目都有章可循。优化点之四是决策评审点的设置在 Charter 开发阶段给出建议，在 Charter 评审时由相应的变革管理团队批准执行。优化点之五是强化架构基础管理，架构按版本的开发和发布机制，为全流程提供规则。优化点之六是将架构要素融合到规划/需求/实施（TR 评审）中，使全流程在有规则的环境中有序运作。优化点之七是建立架构团队，支撑架构的落地。

这些优化点里，最值得拿出来讲的是裁剪原则和TR 评审。裁剪原则解决的是“大项目走全套流程、小项目也要走全套流程导致效率低下”的问题。TR 评审解决的是“DCP 只关注商业决策、不关注技术方案质量”的问题。

3.2 DCP 与 TR 的配合关系：一张表看清谁在什么时候拍板

这张表是根据 PPT 里 BTMS V2.0 优化方案概述部分的流程示意整理的。DCP 关注的是“做不做、继续不继续、投不投”，TR 关注的是“方案对不对、架构合不合规、关联关系清不清楚”。两者配合，才能既保证商业决策的质量，又保证技术方案的质量。

实际落地时，很多公司的 DCP 开成了汇报会，TR 开成了技术评审会，两者之间没有形成闭环。PPT 里强调“将架构要素融合到规划/需求/实施（TR 评审）中”，意思就是 TR 不是走过场，而是要真正检查架构合规性。如果 TR 发现架构问题，DCP 就应该据此做出“暂缓”或“调整”的决策。

3.3 裁剪原则怎么用：不是所有项目都走全套流程

PPT 里说“针对项目的不同特点和复杂程度，对 PMOP 流程设置灵活的裁剪原则，保证大小项目都有章可循”。这句话的实操含义是：你需要先定义一套裁剪矩阵，然后根据项目的预算规模、影响范围、技术复杂度、架构影响度等维度，决定哪些 DCP 和 TR 必须保留、哪些可以合并或简化。

常见做法是：

• A 类项目（预算超过一定阈值、跨多个领域、涉及核心架构变更）：走全套 DCP 和 TR，一个不能少。
• B 类项目（预算中等、影响单个领域、架构影响有限）：保留关键 DCP（Charter Review、CDCP、PDCP、DRR），TR 可以合并为一次技术评审。
• C 类项目（预算较小、影响范围有限、不涉及架构变更）：只保留 Charter Review 和 DRR，中间过程由领域自行管控。

这套裁剪矩阵需要在 Charter 开发阶段就给出建议，并在 Charter 评审时由相应的变革管理团队批准执行。也就是说，裁剪不是项目经理自己说了算，而是要经过变革管理团队批准。这样既保证了灵活性，又防止了“随意裁剪导致管控失效”。

4. 变革使能与管控团队：架构管控、需求管理、业务绩效管理怎么落地

4.1 变革使能的三个支柱：管控组织、规则管理、业务绩效管理

PPT 里对“变革使能”的定义是：包括变革管控组织、规则管理和业务绩效管理，保证变革与公司的业务及技术战略相一致。这三块是横向支撑，不直接参与项目执行，但没有它们，项目执行就会失去方向。

管控组织包括 RSC/3T 管理团队及相关角色、职责。RSC 是最高决策层，3T 是各领域的决策层，Sub-3T 是子领域的决策层。PPT 里多次出现“向 Sub-3T 汇报”“向 C-3T 汇报”“由 RSC 批准”这样的决策控制点，说明这套管控组织是有明确层级的。

规则管理包括架构、变革相关的公司政策/指引、标准等。PPT 里特别强调了“架构管控”，包括架构按版本的开发和发布机制，为全流程提供规则。架构团队要支撑架构的落地，将架构要素融合到规划/需求/实施中。

业务绩效管理通常是通过运用平衡记分卡定义 KPI，管理业务绩效、跟踪变革过程，评估管理体系的效率。PPT 里说“根据 Business Case 衡量 Initiative 的绩效”，意思是每个变革举措都要有明确的 Business Case，然后用 KPI 来衡量它是否达成了预期收益。

4.2 需求管理流程：从需求收集到退出管理的闭环

PPT 里提到“运作管理流程-需求管理流程”，包括需求管理、问题管理、退出管理、变更管理和方案绩效管理。这五个模块构成了一个闭环：需求进来，问题被跟踪，变更被管控，方案绩效被评估，不合适的方案退出。

需求管理的关键在于分类管理。PPT 里提到 BPA（用于对变革需求进行分类管理）。常见做法是：把需求分为“战略级”“业务级”“操作级”三类，战略级需求进入年度规划流程，业务级需求进入领域规划流程，操作级需求由日常运作解决。这样就不会出现“所有需求都往年度规划里塞”的情况。

退出管理是很多公司容易忽略的。项目做到一半发现不可行，或者业务环境变了，需要有明确的退出机制。PPT 里把退出管理放在运作管理流程里，说明它是一个常态化的动作，不是例外。

4.3 架构管控怎么融入全流程：从规划到 TR 评审

PPT 里说“强化架构基础管理，架构按版本的开发和发布机制，为全流程提供规则”，以及“将架构要素融合到规划/需求/实施（TR 评审）中，使全流程在有规则的环境中有序运作”。

实操上，这意味着：

• 规划阶段：专题规划要基于已发布的相关架构，在继承的基础上进行设计。架构方案设计包括 BA/AA/IA/TA。
• 需求阶段：变革需求要经过架构团队审视，确认是否符合目标架构。
• 实施阶段：TR 评审要检查方案是否符合架构规范，架构要素是否落地。
• 架构团队：要建立专门的架构团队，支撑架构的落地，不是挂在某个部门下面兼着做。

很多公司架构管控做不起来，根本原因是架构团队没有实权，或者架构规范没有和项目决策挂钩。PPT 里把架构管控放在变革使能里，并且明确“架构按版本的开发和发布机制”，说明架构是有版本、有发布、有维护的，不是一份静态文档。

5. 避坑与常见问题：PMOP 落地时最容易翻车的五个地方

5.1 现象：年度规划做完了，但项目执行时发现资源不够

原因：规划阶段没有做资源平衡，或者资源平衡只做了 IT 资源，没有考虑业务侧的人力投入。PPT 里明确说“如果某一月份的需求峰值超过了当月可提供的资源，则建议进行需求平衡，将部分项目的启动时间进行调整，避开该峰值”。但实际操作中，很多公司只看了预算，没看人力。

解决：在确定项目短清单时，强制要求各领域提交按月汇总的资源需求，然后由公司整体规划组做峰值检查。如果峰值超标，要么调整项目启动时间，要么增加资源，要么砍项目。这个动作必须在 RSC 批准前完成，否则批了也执行不了。

5.2 现象：DCP 开成了汇报会，决策要素没有真正被审视

原因：DCP 的决策要素没有定义清楚，或者决策人没有提前拿到材料。PPT 里说“优化 DCP 决策要素和决策机制”，说明 V2.0 之前这个问题是存在的。

解决：每个 DCP 都要有明确的决策检查清单，决策人要在会前拿到材料并给出初步意见。会上只讨论分歧点，不从头汇报。决策结果要明确记录：通过、有条件通过、不通过、暂缓。有条件通过的，要明确条件是什么、谁负责、什么时候闭环。

5.3 现象：TR 评审被跳过，架构问题在开发阶段才暴露

原因：项目组觉得 TR 是“技术评审”，和商业决策无关，所以能省就省。或者架构团队人手不够，排不上评审。

解决：把 TR 评审作为 DCP 的前置条件。没有通过 TR 评审的项目，不能进入 DCP 决策。架构团队要提前介入，在 Charter 开发阶段就参与可行性 TR。PPT 里说“增加 TR 评审，对项目方案、架构和关联关系进行技术评审”，说明 TR 不是可选项。

5.4 现象：变革举措和项目的关系混乱，项目各自为战

原因：没有理解“变革举措”的定义。PPT 里说“变革举措由一个或多个相关联的变革项目组成，这些项目都瞄准同一业务目标的达成”。但实际操作中，很多公司把举措当成了一个标签，项目还是各自立项、各自汇报。

解决：在确定变革举措及项目长清单阶段，强制要求每个举措必须有明确的业务目标、明确的举措 Owner、明确的项目清单。举措 Owner 要对举措的整体业务目标负责，而不是只对单个项目负责。项目 PI 要体现对举措目标的支撑关系。

5.5 现象：年度规划报告写完就归档，执行时没人看

原因：年度规划报告没有和项目执行流程挂钩。规划是规划，执行是执行，两张皮。

解决：年度规划报告里的项目短清单、预算、ROI、优先级排序结果，要直接输入到 PMOP 流程的 Charter 开发阶段。每个项目的 Charter 都要引用年度规划报告里的相关结论。执行过程中的变更，如果影响到年度规划确定的预算或优先级，要回到相应的决策控制点重新审批。PPT 里说“根据 Business Case 衡量 Initiative 的绩效”，意思就是规划时定的 Business Case，执行时要拿来衡量。

6. 从 111 页 PPT 里提炼一套可复用的变革管理检查清单

这份 PPT 的信息量很大，但如果你不是华为内部的人，直接照搬全套流程可能会水土不服。我的建议是：先理解它的设计逻辑，然后根据自己公司的规模和成熟度做裁剪。下面是我从 PPT 里提炼的一套检查清单，你可以直接拿去用。

年度规划阶段检查清单：

PMOP 执行阶段检查清单：

这套清单的价值在于：它把 PPT 里散落在各个页面的关键动作，收敛成了可检查的条目。你不需要记住 111 页的内容，只需要在对应阶段问对应的问题。

最后说一个我自己的习惯。每次拿到一份像这样的框架文档，我不会从头到尾读一遍就完事，而是会先找到它的决策控制点和输入输出关系，然后画一张自己的流程图。这张图不追求好看，只追求能回答三个问题：谁在什么时候、基于什么输入、做出什么决策。这三个问题回答清楚了，框架就真正变成你自己的了。从那以后我每次拆解类似 BTMS 或 PMOP 这样的管理体系文档，都强制走一遍这个动作，比单纯读文档效率高得多。希望帮到你。

本文还有配套的精品资源，点击获取