企业身份映射表要解决的是“来源身份”与“目标账号”之间的对应关系：员工从企业目录或HR系统进来，在研发平台、代码仓库、协作工具里各有一个账号，映射表把这两侧稳定地连起来。设计时最关键的两件事是选对主键、建立可执行的校验与维护机制。本文按字段、流程、角色和检查项给出可直接落地的方法，映射关系稳定后，也可在ONES中把账号与工作项、文档的关联纳入日常管理。
要点总览（TL;DR）
- 主键取来源目录中的稳定唯一标识（目录对象ID、员工号），姓名和邮箱会变更或被复用，不宜作为主键。
- 来源ID与目标账号ID分列存放，同一人多账号时按“一人多行、按目标系统区分”表达，每行独立管理状态。
- 字段至少覆盖来源系统、来源唯一ID、目标系统、目标账号ID、映射状态、生效时间与维护人，状态限定为待确认、生效、停用。
- 落地按盘点账号、导出清单、生成初始映射、校验唯一性与孤儿账号、确认发布五步推进，未匹配项单独列出并指定责任人。
- 入职、转岗、离职以新增记录加状态变更留痕，配合定期复核，保证任意时点的账号归属可还原。
映射表先定主键：用哪个字段唯一标识一个人
映射表的主键应取来源目录中的稳定唯一标识，例如目录对象ID、员工号或HR系统的人员主记录ID。这类标识在人员入职时生成，在姓名变更、邮箱调整、部门调动时保持不变，适合作为长期对账的锚点。姓名、邮箱、手机号会变化，也可能被复用（例如离职后邮箱重新分配给新员工），把它们当作主键，后续对账会出现一人多键或一键多人的情况。
基础结构上，来源ID与目标账号ID必须分列存放。常见错误是用一列“账号”同时记录来源工号和目标系统登录名，导入时看似省事，一旦两侧命名规则不同或需要按系统分别统计，就无法拆分核对。建议的最小标识组合是：来源系统标识、来源唯一ID、目标系统标识、目标账号ID，四列共同定位一条映射。
同一人在多个目标系统有账号时，采用“一人多行、按目标系统区分”的方式表达，即同一来源ID对应多行记录，每行指向一个目标系统的一个账号。这样每个目标账号的生效、停用状态可以独立管理，不会因为某个系统换号而影响其他系统的映射。若同一人在同一目标系统存在历史账号与当前账号，也保留为两行，用状态和时间字段区分，避免覆盖。
映射表字段设计：必填列、状态列与时间列
字段设计的目标是让一条记录既能完成账号对应，又能支撑审计和排障。下表给出一份可直接建表的字段定义，必填项是保证映射可用的最低要求，选填项按组织实际需要补充。
| 字段名 | 含义 | 必填 | 示例 |
|---|---|---|---|
| 来源系统 | 人员身份的来源系统标识 | 是 | HR-CORE |
| 来源唯一ID | 来源系统中的稳定唯一标识，映射主键 | 是 | E100238 |
| 来源账号/工号 | 来源系统中展示用的账号或工号 | 是 | zhangsan |
| 姓名 | 人员姓名，便于人工核对 | 是 | 张三 |
| 邮箱 | 企业邮箱，用于通知与辅助匹配 | 否 | zhangsan@example.com |
| 目标系统 | 目标账号所属系统标识 | 是 | DEV-PLATFORM |
| 目标账号ID | 目标系统中的账号唯一标识 | 是 | u_88213 |
| 目标账号名 | 目标系统登录名或显示名 | 是 | zhangsan |
| 映射状态 | 待确认/生效/停用 | 是 | 生效 |
| 生效时间 | 映射开始生效的时间 | 是 | 2025-03-01 |
| 失效时间 | 映射停止生效的时间 | 否 | 2025-09-30 |
| 维护人 | 该条记录的维护责任人 | 是 | 李四 |
| 备注 | 冲突处理、特殊说明等 | 否 | 转岗后新账号 |
必填与选填的划分依据是“缺了它映射是否还能用”。来源唯一ID、目标账号ID、目标系统、状态、生效时间缺失时，记录无法定位或无法判断是否可用，因此必填；邮箱、失效时间、备注属于辅助信息，缺失不影响主流程，但在排障和审计时价值很高，建议尽量填写。状态列建议限定为三个值，避免出现“临时”“冻结”等含义模糊的自定义状态，导致统计口径不一致。
操作步骤：从盘点账号到导入校验
从零建立映射表可以按五步推进，每步都有明确的输入和输出，完成标志是输出物经过责任人确认。
- 盘点账号范围。输入：来源目录与各目标系统的系统清单。动作：确认哪些系统纳入映射管理，明确每个系统的账号字段口径和负责人。输出：系统清单与字段口径说明。完成标志：每个目标系统都有对接人和字段说明。
- 导出两侧账号清单。输入：来源系统与目标系统的账号导出数据。动作：统一编码、日期格式和字段命名，去除测试账号与已注销账号。输出：格式统一的两份账号清单。完成标志：两份清单可按约定字段直接比对。
- 生成初始映射。输入：两份账号清单。动作：优先按来源唯一ID与目标账号的关联字段匹配，其次用邮箱、工号做辅助匹配，匹配不上的单独标注为未匹配项。输出：初始映射表与未匹配清单。完成标志：每条记录都有匹配依据，未匹配项有责任人。
- 校验唯一性与完整性。输入：初始映射表。动作：检查来源唯一ID与目标账号ID的组合是否重复、是否存在一个目标账号被多人占用、是否存在有来源无目标或有目标无来源的孤儿账号。输出：校验报告与修正后的映射表。完成标志：重复项和孤儿账号全部有处理结论。
- 确认并发布生效版本。输入：校验通过的映射表。动作：由审批人确认后，将状态置为生效并记录生效时间，旧版本归档。输出：生效版本映射表与版本记录。完成标志：生效版本可被下游系统或流程引用。
角色分工与交付物：谁维护、谁审批
映射表的责任划分要覆盖“数据从哪来、谁来改、谁批准、谁存档”四个环节，避免出现人人可改、无人负责的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| IT/身份管理员 | 维护主数据与映射表结构，执行批量导入和校验 | 映射表、校验报告、导入记录 |
| HR或业务接口人 | 提供入职、转岗、离职等人员变动信息 | 人员变动清单、变动生效时间 |
| 安全或系统负责人 | 审批高风险映射，如跨部门访问、特权账号对应 | 审批记录、例外说明 |
| 归档责任人 | 保存映射表版本与变更记录，按制度留存 | 版本归档、变更日志 |
高风险映射的界定由组织安全要求决定，常见情形包括映射到管理员账号、映射到外部协作账号、同一来源ID对应多个目标账号。审批层级和复核周期需要结合组织规模与合规要求确定，规模较小的团队可以由身份管理员兼任审批，规模较大的组织建议将审批与执行分离。
示例：一张入职到离职的映射记录
以下示例演示一条映射记录在人员生命周期中的状态流转，字段取值仅作示意。
| 阶段 | 来源唯一ID | 目标系统 | 目标账号ID | 映射状态 | 生效时间 | 失效时间 | 备注 |
|---|---|---|---|---|---|---|---|
| 入职新增 | E100238 | DEV-PLATFORM | u_88213 | 待确认 | — | — | 新员工开通账号 |
| 确认生效 | E100238 | DEV-PLATFORM | u_88213 | 生效 | 2025-03-01 | — | 审批通过 |
| 转岗换号 | E100238 | DEV-PLATFORM | u_90517 | 生效 | 2025-07-01 | — | 原账号停用，新增一行 |
| 离职停用 | E100238 | DEV-PLATFORM | u_90517 | 停用 | 2025-07-01 | 2025-09-30 | 离职，账号回收 |
要点在于：入职时新增一行并置为待确认，确认后补生效时间；转岗或换账号时新增记录，旧记录置为停用并补失效时间，不覆盖原行；离职时对当前生效记录置为停用并记录失效时间。这样任何时点的账号归属都能从历史记录中还原，审计时不会出现断链。
完成检查：映射表可用的判断标准
投入运行前，用以下清单逐项核对，全部通过再发布为生效版本。
- 主键唯一：来源唯一ID与目标账号ID的组合无重复，抽查若干条记录可人工复核。
- 覆盖清晰：来源与目标账号的覆盖率有统计，未匹配清单逐条有责任人和处理结论。
- 状态完整：每条记录都有映射状态，生效记录有生效时间，停用记录有失效时间。
- 变更可追溯：转岗、换号、离职均以新增或状态变更留痕，旧记录未被覆盖。
- 流程明确：新增、变更、离职的处理流程和审批人有书面约定，相关角色知晓。
- 复核机制：约定定期复核周期，复核内容包括孤儿账号、长期待确认记录和异常映射。
映射表稳定运行后，账号与具体工作对象之间的关联也需要有承载方式。在ONES中，成员账号可以与工作项、文档建立关联，人员变动时通过成员状态和项目权限的调整保持对应关系，映射表则作为账号口径的核对依据，两者配合可以减少人工比对的工作量。
常见问题
来源系统没有稳定的员工号，只有邮箱，映射表还能建吗？
可以建，但需要先补一个稳定标识。常见做法是以来源目录的对象ID作为主键，邮箱只作为辅助匹配字段；如果来源系统确实只提供邮箱，建议在映射表中增加一列内部人员编号，由HR或身份管理员在首次导入时生成并长期维护，后续所有记录都以该编号为准。邮箱发生变化时只更新邮箱列，主键保持不变，对账链条不会断。
同一个人在同一目标系统有新旧两个账号，应该删掉旧记录还是保留？
保留旧记录，把旧行置为停用并补失效时间，新账号另起一行置为生效。删除旧记录会让历史时点的账号归属无法还原，审计或排障时找不到依据。保留两行后，按生效时间和失效时间就能判断任意日期该人员实际使用的是哪个账号，也便于在账号回收时核对是否还有未停用的记录。
映射表建好后，人员变动频繁，怎么保证它不过期？
把变动信息的来源固定下来是关键。与HR或业务接口人约定人员变动清单的提供频率和字段口径，入职、转岗、离职都在清单中体现，身份管理员按清单更新映射表并记录生效时间。同时约定定期复核周期，重点核对长期处于待确认状态的记录、有来源无目标的孤儿账号，以及已离职但映射仍为生效的记录。复核周期和频率结合组织人员流动情况确定。
映射表校验时发现一个目标账号对应了多个来源人员，怎么处理？
这类情况通常来自账号共用或历史数据错误，需要逐条确认。先查该目标账号的实际使用人，若确属共用账号（如公共构建账号），在备注中说明用途并单独标记，不纳入个人映射统计；若属于误匹配，修正目标账号ID后重新校验。处理结论要写入校验报告，避免同一问题在下次导入时重复出现。
映射表需要和单点登录、组织架构同步配合吗？
映射表解决的是账号对应关系的记录与核对，单点登录和组织架构同步解决的是认证与人员数据的自动流转，两者可以配合使用。组织架构同步能减少手工维护来源字段的工作量，映射表则用于核对同步结果、处理同步覆盖不到的例外账号。具体采用哪种同步方式，取决于现有目录系统和目标平台的对接条件，落地前需要确认字段口径是否一致。
