EA之家TOGAF系列【3】：TOGAF利益相关者管理：四象限怎么用？一套完整的分析与管理方法

附件为46页PDF。

企业架构工作中，经常会遇到这样的情况：架构方案本身已经比较成熟，但业务部门迟迟不给确认；有些关键人员直到方案评审时才提出不同意见；还有一些真正受架构变化影响的人，前期根本没有参与。

这些问题往往与利益相关者管理有关。

TOGAF将利益相关者管理作为架构开发过程中的一项重要工作。从识别利益相关者、分析其立场与状态，到确定管理策略，再到将关注点转化为架构需求和决策，形成了一套相对完整的方法。

其中，权力与关注程度四象限矩阵，是确定利益相关者管理方式的重要工具。

一、利益相关者管理，首先要解决两个问题

利益相关者管理有两个基本问题：应该管理谁，以及应该怎么管理。

第一个问题是识别。需要从不同角度梳理与架构事项有关的人员和组织，包括决策角色、业务角色、技术角色、管理角色以及外部角色，形成利益相关者初始清单。

这里需要注意，识别和分类是两个不同的步骤。识别阶段首先要尽可能避免遗漏，不能一开始就只关注领导和项目负责人。

第二个问题是分析。找到利益相关者之后，还需要判断他们与架构工作的关系、当前立场、理解程度、支持程度，以及对架构结果的影响能力。

其中有两个维度尤其需要区分：

一是理解程度（Understanding）。 利益相关者是否理解架构目标、方案内容和相关影响？目前掌握了哪些信息，还存在哪些认识偏差？

二是支持程度（Support）。 利益相关者是否认可架构目标，愿意参与相关工作，并为架构实施提供必要支持？

理解和支持是两回事。一个人可能充分理解架构方案，但并不认可其中的业务调整；也可能愿意支持项目，却还不了解方案具体要解决什么问题。

因此，利益相关者分析需要同时看当前状态和所需状态，找到二者之间的差距。管理工作的重点，就是缩小这些差距。

二、四象限怎么划分？关键看权力和关注程度

完成利益相关者识别和状态分析之后，还需要判断管理资源应该投入在哪里。

TOGAF采用权力或影响力（Power/Influence）与关注程度（Interest）两个维度，确定不同利益相关者的管理方式。

权力或影响力，主要看三个方面：能否影响关键决策、能否控制资源、能否促进或阻碍架构变更。

关注程度，则主要看架构事项与其自身利益的相关性、关注的深度与持续性，以及愿意为相关事项投入多少精力。

两个维度组合起来，形成四种管理策略。

1. 高权力、高关注：重点管理（Key Players）

这类人员既能影响架构结果，也高度关注架构事项，需要深度参与关键工作。

管理重点是让他们参与方案讨论、关键评审和重要决策，及时处理分歧，保持必要的沟通。

2. 高权力、低关注：保持满意（Keep Satisfied）

这类人员具有较强的影响力，但不需要持续参与架构工作的所有细节。

管理重点是让其了解关键事项、重大风险和重要决策，在需要支持的节点及时沟通，保持必要的认可。

3. 低权力、高关注：持续告知（Keep Informed）

这类人员对架构结果比较关心，但通常没有直接决定总体方案的权力。

管理重点是保持信息透明，及时告知架构变化，适当收集意见和反馈，让他们了解架构工作对自身的影响。

4. 低权力、低关注：最低必要投入（Minimal Effort）

这类人员对当前架构事项的影响力和关注程度都较低。

管理重点是提供必要信息，保持适度沟通，并关注其角色和关注程度是否发生变化。

四种策略并不复杂，真正需要注意的是：它们针对的是具体架构事项，不能简单根据一个人的职务高低来确定分类。同一个人面对不同架构事项，可能处于不同象限。

四象限解决的是管理优先级问题，帮助架构团队判断谁需要重点参与、谁需要保持沟通，以及管理精力应该如何分配。

三、分类之后，还要制定差异化管理策略

知道了应该重点管理谁，还需要进一步判断具体采取什么行动。

前面提到的理解程度和支持程度，在这里就发挥作用了。

将当前理解程度与支持程度放在一起分析，可以识别出不同的管理状态：

• 理解不足，但支持较高： 需要补充信息、解释架构目标和方案影响。
• 理解不足，支持也不足： 需要重点沟通，增加参与机会，弄清楚其顾虑。
• 理解较高，但支持不足： 需要分析利益冲突，协调不同诉求，必要时开展方案权衡。
• 理解充分，支持充分： 保持参与，发挥其推动作用。

这里有一个重要区别：理解和支持的目标，不要求所有人都达到同一个水平。

决策者需要理解核心方向，并支持关键决策；业务负责人需要理解业务影响，参与方案讨论和业务验证；普通员工可能只需要了解必要变化，能够接受并正确使用。

管理目标应该与利益相关者的角色、职责和参与方式相匹配。

完成状态分析后，还要进一步结合权力和关注程度，确定管理投入的优先级。

最终需要形成一份具体的利益相关者管理计划，至少明确五项内容：管理对象、目标状态、管理动作、责任人，以及时间与沟通频率。

只有把这些内容落实下来，利益相关者管理才能从分析结果变成日常工作安排。

四、利益相关者的关注点，如何进入架构设计？

前面的工作解决了人的问题。对于企业架构师来说，还有一个更关键的问题：如何把不同利益相关者的诉求转化为架构设计要求？

这里需要区分三个概念：

关注点（Concern）回答利益相关者关心什么、担心什么。

架构需求（Architecture Requirement）明确架构必须满足什么要求。

架构决策（Architecture Decision）确定最终采用什么设计方案。

三者之间存在清晰的关系：

利益相关者提出关注点，架构团队分析并形成架构需求，再通过方案比较和决策确定实现方式。

需要注意，并非所有关注点都要直接转化为架构需求。架构师还需要判断其业务依据、适用范围、约束条件，以及是否属于架构层面需要解决的问题。

更复杂的情况是，不同利益相关者的关注点可能相互冲突。

例如，集团希望统一管理，业务部门希望保留灵活性；员工希望操作方便，安全管理要求严格控制数据访问；项目团队希望快速上线，架构治理又要求遵循企业标准。

架构师需要分析这些诉求背后的价值、成本、风险和约束，比较不同方案，形成可解释、可追溯的架构决策。

方案形成后，还需要由相关利益相关者参与验证，主要包括三个方面：

• 业务验证： 是否支持业务战略和目标，是否满足业务及用户需求。
• 专业验证： 技术方案、数据架构和安全设计是否可行，是否满足相应要求。
• 治理验证： 是否符合企业架构原则与标准，是否满足法规和合规要求，风险是否可控。

至此，利益相关者管理才真正进入架构开发和治理过程。

五、结合集团人力资源系统，看一套方法如何落地

前面讲的是方法，下面结合 PPT 中的集团人力资源系统案例，把整个过程串起来。

第一步：形成利益相关者初始清单。

案例中识别了集团领导、HR负责人、业务负责人、员工和IT负责人等角色，后续分析还纳入了审计合规人员。

这些角色与架构事项的关系不同，主要关注点也不同：

• 集团领导：人才结构、组织效率。
• HR负责人：制度、流程、数据。
• 业务负责人：招聘、配置、绩效。
• 员工：薪酬、体验、隐私。
• IT负责人：集成、安全、稳定。
• 审计合规人员：权限、控制、留痕。

这张清单解决的是有没有遗漏的问题，为后续分析提供基础。

第二步：分析当前状态，找到真正需要重点管理的对象。

PPT中的状态分析表，对不同利益相关者的当前理解、所需理解、当前支持和所需支持进行了对比。

其中，业务负责人的差距比较明显：

• 当前理解程度：中。
• 所需理解程度：高。
• 当前支持程度：低。
• 所需支持程度：高。

集团领导和HR负责人已经具备较好的理解和支持基础，员工需要达到的理解和支持程度相对适中，IT负责人整体状态较好。

因此，业务负责人被列为优先关注对象。原因很明确：他既存在较大的理解和支持差距，又是业务落地的重要参与者。

第三步：结合权力和关注程度，确定管理策略。

在利益相关者地图中，集团领导、HR负责人和业务负责人属于高权力、高关注对象，采取重点管理策略；员工属于低权力、高关注对象，采取持续告知策略；审计合规人员具有较高影响力，但关注程度相对较低，采取保持满意策略。

这样，架构团队就能明确不同人员的参与方式，不必让所有人参加同样的会议。

第四步：针对业务负责人制定管理计划。

PPT中给出了一个具体安排：

这就把分析结果落实成了实际工作。架构团队需要与业务负责人共同讨论业务规则、方案影响和业务差异，通过业务验证解决实际顾虑。

第五步：把关注点转化为架构需求，并完成方案权衡。

PPT中列出了三个典型的关注点及对应的架构需求：

这些需求之间可能存在冲突。

集团希望统一流程和标准，业务部门希望保留灵活性。PPT给出的权衡方案是：

集团统一流程，同时允许少量经过治理的业务差异配置。

统一性体现在集团标准、流程一致和数据可比；灵活性体现在满足合理业务差异，通过受控配置实现，并保证合规可管。

最后，方案还需要经过业务、专业和治理三个方面的验证，确认设计真正满足相关要求。

从这个案例可以看到，利益相关者管理贯穿了从人员识别到架构决策的全过程。四象限帮助确定管理优先级，状态分析帮助找到管理差距，管理计划明确具体行动，关注点分析则进一步影响架构需求和方案设计。

对于企业架构师来说，利益相关者管理最终要解决的，是让正确的人在正确的阶段参与正确的架构问题，并让他们的合理诉求真正进入架构决策。

五、46页PDF