干系人识别不是凭经验列名单，而是从项目文件、组织信息、合同商务、历史记录和外部环境中逐项取证。本文给出五类依据的核对清单、五步操作流程、角色分工、登记册填写示例和完成检查表，帮助项目团队把依据转化为可评审的干系人清单。
要点总览（TL;DR）
- 干系人识别的依据分为五类：项目文件、组织与角色信息、合同与商务文件、历史经验记录、外部环境信息；其中项目章程和范围文件权威性最高，出现冲突时以其为准。
- 操作按五步推进：用章程、范围说明书和WBS定边界，从组织架构与RACI提角色，梳理合同与监管关系，查阅历史记录查漏，最后汇总为带依据出处的干系人登记册初稿。
- 项目经理牵头并最终确认，核心成员按领域提供候选名单，PMO提供模板与历史数据，商务或采购提供合同相对方与分包方信息。
- 识别完成的判断标准是：每条记录有可追溯的依据来源，组织内、组织外、合同方、监管方四类均已判断，与项目文件核对一致，且经过核心成员评审并留下异议记录。
- 登记册初稿、依据清单和评审记录齐备后即可移交干系人分析环节，后续参与度评估与沟通计划以此为基础。
干系人识别要准备哪些依据
干系人识别的依据可以归为五类来源。它们的共同作用是为“谁与项目有关、为什么有关”提供可追溯的证据，避免仅凭印象列名单。准备阶段建议先把项目章程和范围文件放在手边，因为这两份文件确定了项目目标、交付物和边界，是判断相关方是否与项目直接相关的首要依据。
| 依据类别 | 典型文件或信息 | 解决的识别问题 | 使用时机 |
|---|---|---|---|
| 项目文件 | 项目章程、范围说明书、WBS、里程碑计划 | 项目要交付什么、涉及哪些业务领域和部门 | 识别启动时首先使用，建立项目边界 |
| 组织与角色信息 | 组织架构图、岗位职责、RACI矩阵、治理委员会名单 | 哪些岗位对项目有审批权、资源权或执行责任 | 边界明确后补充内部角色 |
| 合同与商务文件 | 合同、采购订单、供应商协议、外包工作说明书 | 哪些外部方因合同关系与项目绑定 | 涉及采购、外包或甲乙方关系时使用 |
| 历史经验记录 | 以往项目干系人登记册、经验教训库、问题日志 | 过去哪些相关方被遗漏或引发过冲突 | 初步名单形成后用于查漏 |
| 外部环境信息 | 监管要求、行业规范、社区或媒体关注信息 | 哪些组织外主体对项目有约束或关注 | 项目涉及合规、公共影响时补充 |
五类依据的权威性并不相同。项目章程和范围文件经过正式批准，对项目目标和边界的描述最权威，出现冲突时应以它们为准；组织架构和合同文件次之，反映正式的权利与义务关系；历史记录和外部信息适合作为补充线索，引用时需要核实其与当前项目的相关性。为便于后续核对，可以先用一张依据清单登记每类依据的来源、用途和责任人，再进入实际收集。
按步骤完成一次干系人识别
识别活动按“定边界—提角色—理关系—查历史—汇清单”的顺序推进，每一步都有明确的输入、动作、输出和完成标志。前一步的输出是后一步的输入，这样能保证名单逐步扩展而不是重复劳动。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：建立项目边界 | 项目章程、范围说明书、WBS | 列出项目目标、主要交付物、涉及的业务领域和部门，标出范围之外的事项 | 项目边界说明，含涉及领域清单 | 核心成员对项目范围和涉及领域无重大分歧 |
| 第二步：提取组织角色 | 组织架构图、岗位职责、RACI矩阵 | 按业务领域逐一对照，找出有审批、决策、资源调配和执行责任的岗位 | 内部角色候选名单 | 每个涉及领域至少对应到具体岗位而非笼统部门 |
| 第三步：梳理合同与监管关系 | 合同、采购订单、供应商协议、监管要求 | 识别合同相对方、分包方、监管或合规主体，记录其与项目的权利义务关系 | 外部相关方候选名单 | 合同类相关方与合同文本可一一对应 |
| 第四步：查阅历史记录 | 历史干系人登记册、经验教训库、问题日志 | 对照当前项目，找出过去被遗漏或引发过问题的相关方，判断是否适用 | 补充候选条目及遗漏提示 | 历史记录中的相关方已逐条判断保留或排除 |
| 第五步：汇总登记册 | 前四步的全部候选条目 | 合并重复条目，为每条记录标注依据出处，形成干系人登记册初稿 | 干系人登记册初稿 | 每条记录均有依据来源，可进入评审 |
第三步需要特别注意合同链条的完整性。直接签约的供应商容易识别，分包方和实际服务提供方常被忽略，而他们往往影响交付进度。第四步的价值在于发现“过去踩过的坑”，例如某次项目中未纳入的运维团队在验收阶段提出大量问题，这类记录应转化为当前项目的检查提示。
第五步汇总时，同一相关方可能从多个来源被识别，例如某部门负责人既是组织角色又是治理委员会成员，应合并为一条记录并注明全部依据。登记册初稿完成后即可组织评审，评审通过后转入干系人分析环节。
谁负责收集，各角色交付什么
识别活动由项目经理牵头，但依据分散在不同角色手中，需要明确分工，避免出现“都以为别人会提供”的情况。下表按依据来源列出责任角色和交付物。
| 角色 | 负责的依据来源 | 交付物 |
|---|---|---|
| 项目经理 | 项目章程、范围说明书、整体协调 | 项目边界说明、干系人登记册初稿、评审组织与最终确认 |
| 核心团队成员 | 各自业务领域的岗位职责、RACI、领域内相关方 | 本领域的角色候选名单及依据说明 |
| PMO或项目管理办公室 | 登记册模板、历史项目干系人清单、经验教训库 | 模板、历史数据摘录、遗漏提示 |
| 商务或采购角色 | 合同、采购订单、供应商协议 | 合同相对方与分包方清单、权利义务说明 |
分工确定后，建议在项目启动会上明确各角色的提交时间，并把登记册初稿的汇总责任落在项目经理身上。核心团队成员提交的候选名单应附带依据说明，例如“依据RACI矩阵，该岗位对验收签字负责”，便于评审时核对。PMO提供的历史数据需要说明适用条件，历史项目与当前项目在业务领域、合同结构上的差异应一并注明。
当项目使用协作工具承载识别过程时，可以把每条候选相关方作为工作项记录，附上依据来源和提交人，评审意见也留在同一条记录下。ONES的项目工作项与文档可以承载这类登记册和评审记录，使依据出处与评审结论保持在同一处，便于后续分析阶段直接引用。工具只是承载方式，分工和交付标准仍需团队事先约定。
一个干系人登记册的填写示例
以下为演示情景，用于说明依据如何转化为登记册条目。假设某企业启动一套内部报销系统的升级项目，项目涉及财务、IT、各业务部门以及一家外部实施商。
| 干系人 | 类别 | 依据来源 | 影响 | 利益 | 初步态度 |
|---|---|---|---|---|---|
| 财务部负责人 | 组织内 | 项目章程列明的业务发起部门；RACI矩阵中为验收签字人 | 高，掌握验收与预算 | 高，关注报销合规与效率 | 支持 |
| IT运维主管 | 组织内 | 组织架构中负责系统上线后的运维；历史项目问题日志显示曾因交接不清产生故障 | 中，影响上线后的稳定性 | 中，关注运维交接质量 | 中立，需提前介入 |
| 外部实施商项目经理 | 合同方 | 实施合同及工作说明书 | 高，负责交付实施 | 高，关注验收与回款 | 支持 |
| 实施商分包的数据迁移团队 | 合同方 | 分包协议；合同链条梳理时发现 | 中，影响历史数据迁移进度 | 中，关注迁移范围界定 | 未知，需接触确认 |
| 数据合规监管对接人 | 监管方 | 行业数据管理要求；外部环境信息 | 中，对数据存储与使用有约束 | 低，关注合规性 | 中立 |
逐条看依据的作用：财务部负责人的条目由项目章程和RACI共同支撑，说明其既有业务发起身份又有验收权力，因此影响和利益都判为高。IT运维主管的条目来自组织架构和历史问题日志两类依据，历史记录提示了交接风险，所以初步态度标为“中立，需提前介入”，而不是简单写“支持”。分包团队是合同链条梳理的产物，若只看主合同就会遗漏，其态度尚未接触，如实标注为未知。监管对接人的依据来自外部环境信息，影响中等但约束明确，需要在分析阶段评估其具体要求。
示例中的影响、利益和态度是初步判断，作用是给后续分析提供起点。登记册的价值在于每条记录都能回答“依据是什么”，评审时可以逐条追问来源，而不是争论印象。
识别完成前要检查什么
识别活动可以结束的标志是：登记册经过核心成员评审，条目有依据、覆盖面无明显缺口、与项目文件一致。以下检查表可逐项核对。
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 依据完整性 | 每条干系人记录均标注依据来源，来源可追溯到具体文件或信息 | 补充来源或删除无依据条目 |
| 覆盖范围 | 组织内、组织外、合同方、监管方四类均有对应条目，或已说明某类不适用的理由 | 回到对应步骤补充识别 |
| 与项目文件一致 | 登记册中的业务领域和交付相关方与项目章程、范围文件核对一致 | 修正条目或澄清范围 |
| 评审记录 | 核心成员已评审，异议已记录并处理或标注待定 | 组织补充评审 |
| 交接条件 | 登记册初稿、依据清单和评审记录齐备，可移交分析环节 | 补齐材料后再交接 |
覆盖范围检查中，四类相关方并非每个项目都同等重要，但每类都应经过判断。例如纯内部项目可能没有合同方，此时应在检查表中注明“本项目无外部合同方”，而不是跳过该项。与项目文件核对时，重点看登记册是否遗漏了章程中明确提到的部门或角色，以及是否纳入了范围之外的相关方。
评审记录是容易被省略的一环。核心成员提出的异议，无论是“某部门也应纳入”还是“某供应商与本项目无关”，都应留下记录和处理结论，这样分析阶段遇到疑问时可以回溯。交接条件满足后，登记册进入干系人分析，后续的参与度评估和沟通计划都以此为基础。
常见问题
项目刚启动，章程和范围文件还没定稿，能先做干系人识别吗？
可以先做一轮初步识别，但要明确标注为待确认版本。此时可先用已有的立项材料、业务需求说明和已知的组织关系列出候选相关方，重点覆盖业务发起部门、审批岗位和已知的外部合同方。等章程和范围文件定稿后，再以它们为基线复核一遍，重点检查两件事：章程中明确提到的部门和角色是否都已纳入，以及初步名单中是否有超出项目范围的相关方需要移出。复核结论应更新到登记册并注明版本，避免后续分析阶段引用过期名单。
小型内部项目没有合同方和监管方，检查表里这几类怎么处理？
四类相关方的作用是提醒逐类判断，并非要求每个项目都必须有对应条目。项目确实不涉及外部合同或监管约束时，在检查表中写明“本项目无外部合同方”“本项目不涉及特定监管要求”及判断理由即可，这样评审时能看出该类是被判断过而非被遗漏。需要留意的是，内部项目仍可能存在间接的合同关系，例如使用外部云服务或外包运维，这类关系应回到合同与商务文件一步确认后再下结论。
历史项目的干系人清单可以直接复用吗？
适合作为查漏线索，不宜直接照搬。复用前要判断两个项目在业务领域、组织结构和合同结构上的差异：业务领域不同，涉及的部门和外部方会变化；组织结构调整后，原岗位可能已合并或撤销；合同结构不同，分包方和监管关系也会不同。建议逐条判断保留或排除，并写明理由，把历史上被遗漏或引发过冲突的相关方转化为当前项目的检查提示，而不是原样复制条目。
评审时核心成员对某条相关方是否纳入有分歧，怎么处理？
把分歧记录在对应条目下，写明各方理由和所依据的文件，再按依据的权威性判断：与项目章程、范围文件一致的判断优先；涉及权利义务的以合同文本为准；仅凭印象的争议先标为待定，安排补充取证。暂时无法定论的相关方可以保留在登记册中并标注“待确认”，在分析阶段继续核实，避免因争议卡住整体进度。关键是留下记录，让后续接手的人能看到判断过程和未决事项。
识别出的相关方很多，登记册要不要分级管理？
条目较多时可以在登记册中增加分组字段，例如按组织内、合同方、监管方分类，或按影响程度初步分层，便于评审和分析时分批处理。分级只用于组织信息，不替代逐条的依据标注，每条记录仍需能回答“依据是什么”。分层标准由项目团队根据项目复杂度约定，并在评审时说明，避免不同成员按各自理解分类导致口径不一致。
