附件为50页PDF文件。
在TOGAF 10 中，Stakeholder（利益相关者）是一个非常基础的概念。
但真正做企业架构时，这个概念反而经常说不清楚。
客户当然算。领导算不算？业务部门、普通员工、IT、财务、审计算不算？系统外部的供应商、监管机构又算不算？
很多项目最后会列出一长串人员和部门，却没有回答一个更重要的问题：
为什么这些人是利益相关者？
其实，利益相关者并不是一类固定的人，也不存在一张可以套用到所有项目里的标准名单。
利益相关者一定是相对于某个分析对象而言的。
TOGAF 对 Stakeholder（利益相关者）的定义是：
Stakeholder：An individual, team, organization, or class thereof, having an interest in a system.
也就是：对某个系统具有利益、关注或利害关系的个人、团队、组织或一类群体。
真正需要理解的是其中的 interest。它并不只是经济利益。如果一个人或者组织能够影响这件事，会受到这件事的影响，对结果承担责任或者风险，或者拥有明确的权利、诉求和约束关系，他就可能是利益相关者。
最简单的判断：看他和这件事有没有实质关系，而不是看他是不是项目成员，也不是看他的职位高不高。
一、到底谁是利益相关者？看一个人力资源管理系统就明白了
假设一家大型集团准备建设一套统一的人力资源管理系统，覆盖组织、人事、招聘、绩效、薪酬、培训和员工服务。
谁是利益相关者？
首先是人力资源部门。因为大量人力资源制度、流程和管理要求最终都需要通过这套系统运行。
集团领导也是。领导可能很少直接使用系统，但他关心企业有多少人、人才结构是否合理、关键岗位是否缺人、人工成本是否可控。系统需要支撑这些经营和管理决策。
业务部门负责人也是。他要招聘、用人、调人、做绩效评价。系统如何设计，会直接影响日常管理。
员工也是。请假、调动、考勤、绩效、薪酬查询、培训、个人信息维护，都可能在这套系统中完成。
财务、IT、审计、法务、合规和安全部门也可能是。财务关心薪酬和人工成本，IT负责系统建设和运行，审计和合规关注制度执行、权限控制和过程留痕，安全部门关注个人信息和敏感数据保护。
只要与这套业务存在稳定的业务、数据或者规则关系，也可能进入特定范围下的利益相关者分析。
这样一看就会发现：利益相关者和“系统用户”根本不是一回事。
员工可能每天登录系统，是用户，也是利益相关者。
集团领导可能一年也不登录几次，却仍然是关键利益相关者。
审计部门甚至不负责日常使用，但它提出的要求可能直接决定系统必须保存哪些数据、记录哪些操作。
所以：用户回答“谁在使用系统”，利益相关者回答“谁与这件事存在利害关系”。这两个概念不能混在一起。
二、识别利益相关者，第一步不是找人，而是先确定“这件事”
一上来就问：“有哪些利益相关者？”这个问题其实并不完整。
应该先问：“什么事情的利益相关者？”
还是人力资源这个例子。
如果研究的是集团人力资源管理体系，那么高管、人力资源部门、业务负责人、员工、财务、IT、审计、外部服务机构等都可能进入范围。
如果研究的是人力资源管理系统建设，范围会进一步聚焦到系统建设和运行相关的角色。
如果只是优化一个员工请假审批功能，范围还会更小。
同一个角色，在不同分析对象下，重要程度也可能完全不同。
因此，利益相关者识别的第一步永远是：明确我们正在研究什么，以及研究边界在哪里。边界没有确定，就谈不上谁真正相关。
三、对象确定以后，怎么把利益相关者找出来？
真正做项目时，不需要照着组织架构图逐级点名。
更有效的方法，是围绕分析对象连续追问几个问题。
1. 谁决定这件事？
谁决定目标、投资、范围和重大原则？
在人力资源管理系统中，可能包括集团领导、人力资源分管领导和人力资源负责人。
2. 谁会直接受到影响？
系统上线后，谁的工作方式会发生变化？
比如人力资源专员、业务部门负责人和普通员工。
这些人不一定拥有最高的决策权，却往往是变化最直接的承受者。
3. 谁负责把业务运行起来？
招聘、组织、人事、薪酬、绩效、培训分别由谁负责？
这些角色掌握真正的业务规则。
如果只访谈管理层，忽略实际运行人员，很容易得到一套原则正确、但落不下去的方案。
4. 谁负责建设和长期运行？
包括 IT、数据、安全、运维等角色。
他们关心系统如何集成、数据如何交换、安全如何保证，以及未来能不能持续运行。
5. 谁负责监督、约束或者制定规则？
包括财务、审计、法务、合规、安全，以及必要情况下的外部监管机构。
这类利益相关者很容易被漏掉。
他们未必参与日常业务，却可能决定：哪些事情必须做，哪些事情不能做。
6. 谁与企业共同完成这项业务？
还要向企业边界之外再看一步。
例如招聘服务机构、培训机构、测评机构等。
只要企业的业务结果依赖它，或者架构变化会改变双方的业务和数据关系，就应该判断它是否属于利益相关者。
所以：组织边界不等于利益相关者边界。人可以在企业外部，但关系仍然在业务里面。
四、找到“谁”以后，更重要的是继续问：他关心什么？
到这里，其实只完成了利益相关者分析的一半。
TOGAF 还有一个非常重要的概念：Concern（关注点）。
仅仅知道“领导、人力资源部门、员工、IT都是利益相关者”，并不能直接指导架构设计。
还必须知道他们分别在关心什么。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这时候就会发现：大家面对的是同一套系统，但关心的并不是同一件事。
集团领导看到的是组织和人才；人力资源部门看到的是制度和流程；员工看到的是工作体验和个人权益；财务看到的是成本；审计看到的是风险和规则；IT看到的是系统能不能长期稳定运行。
这也是TOGAF 为什么会把下面几个概念联系起来：
Stakeholder（利益相关者）→ Concern（关注点）→ Viewpoint（架构视点）→ View（架构视图）
可以简单理解为：利益相关者决定“谁在看”，关注点决定“他想看什么”，架构视图负责把答案表达出来。
所以企业架构不应该一开始就问：
还应该先问一句：这张图准备给谁看？需要回答他的什么问题？
五、关注点还要继续转成架构需求
利益相关者说：“希望系统好用。”这只是一个Concern（关注点），还不能直接指导架构设计。
需要继续往下分析。
为什么不好用？是不是多个系统重复登录？是不是一个请假流程要经过很多节点？是不是个人信息需要反复填写？是不是移动端无法办理？
分析到这一层，才可能形成真正的 Architecture Requirement（架构需求）。
例如：集团领导关注人工成本。可能进一步形成组织编制管理、人力成本分析、薪酬预算等能力和数据要求。
业务部门负责人关注招聘周期。可能进一步形成用人需求、招聘审批、候选人管理和入职流程优化要求。
员工关注薪酬准确。就会涉及考勤、人事、薪酬规则、数据质量，以及与财务系统之间的数据关系。
审计关注过程可追溯。则可能进一步形成审批留痕、权限记录、关键数据变更记录和审计日志等要求。
所以完整的关系应该继续往下延伸：
Stakeholder（利益相关者）→ Concern（关注点）→ Architecture Requirement（架构需求）→ Architecture（架构设计）
这也是企业架构中的利益相关者分析，与简单“需求收集”之间一个很重要的区别。
如果一上来就问：“你希望系统增加什么功能？”
很容易得到一份越来越长的功能清单。
企业架构需要再往上追一层：
你为什么关心这个问题？你的目标是什么？承担什么责任和风险？这个关注最终要求架构解决什么问题？
这样得到的，才更接近真正的架构需求。
六、国内项目其实一直在做，只是过去比较分散
在人力资源系统项目中，我们通常都会做这些事情：
领导访谈、人力资源业务调研、业务部门访谈、员工问卷、财务需求确认、IT架构设计、安全评审、审计和法务审核。
这些工作并不陌生。
从TOGAF 的角度看，它们其实都在处理不同 Stakeholder（利益相关者）的 Concern（关注点）。
真正的问题是，这些工作经常分散进行。领导有领导的要求；人力资源部门有业务需求；员工提出使用需求；IT形成技术方案；安全和审计到了后期才进入。最后每个人说得都有道理，但大家的关注点没有被放到一起分析。有些要求彼此重复，有些要求相互冲突，还有些关键角色一开始就被漏掉。
利益相关者分析的价值，就是把这些分散的要求重新放回同一套架构逻辑中：谁与这件事有关？他为什么相关？他真正关心什么？不同人的关注有没有冲突？哪些关注应该转成架构需求？
这样，利益相关者才真正从一张“人员名单”，进入企业架构。
七、回到最初的问题：到底谁是利益相关者？
所以，TOGAF 10中的利益相关者到底是谁？
没有一张固定名单。员工可能是，领导可能是，客户可能是；业务部门、财务、IT、审计、安全可能都是；供应商、合作伙伴、监管机构同样可能是。
真正的判断标准始终是：围绕我们正在研究的对象，谁能够影响它，谁会受到它的影响，谁对结果承担责任或者风险，谁拥有明确的权利、诉求和约束关系。这些人，就是利益相关者。
而企业架构还要继续往下问：他们分别关心什么？这些关注最终要求架构解决什么问题？因此，TOGAF 里的几个概念最好连起来理解：
Stakeholder（利益相关者）解决“谁”；Concern（关注点）解决“关心什么”；Architecture Requirement（架构需求）解决“架构必须满足什么”；Viewpoint / View（架构视点 / 架构视图）解决“如何把架构表达给相关的人看”。
理解了这条线，再回过头看利益相关者，就会发现它并不是项目启动阶段附带做的一张人员表。它实际上决定了企业架构从哪里开始。
把这条线串起来，再回头看利益相关者，就会发现它并不是项目启动阶段附带做的一张人员表。它实际上决定了架构从哪里开始，也决定了架构为什么这样设计。
因为任何一项架构设计，本质上都在做选择。
流程是追求效率，还是增加控制？系统是强调统一，还是保留灵活性？数据是扩大共享，还是加强隔离？
这些看似是流程、应用、数据和技术问题，往前追一层，往往都来自不同利益相关者的不同关注。
所以，在讨论业务能力、流程、数据、应用和技术之前，企业架构至少应该先把三件事说清楚：这套架构到底与谁有关？他们真正关心什么？当这些关注彼此冲突时，我们依据什么做出选择？
这可能才是 TOGAF 把利益相关者放在架构方法前端的真正意义。
八、从规范到实践，50页PDF利益相关者详解
EA之家 » EA之家TOGAF系列【2】：TOGAF10核心概念：利益相关者、关注点与架构需求。TOGAF中的利益相关者是谁？如何识别利益相关者？
