研发平台接入SSO的投入，通常由身份治理、实施对接和持续运维三块构成。立项估算时，先界定接入应用数、用户规模、目录数量以及建设期与运维期长度，再按人力投入和一次性、周期性费用分列。本文给出一套可复算的框架与示例假设，具体价格、版本兼容与认证结论需按实际厂商方案查证。
要点总览（TL;DR）
- SSO接入投入分三块：身份治理（账号与组织架构梳理、唯一身份源、生命周期规则）、实施（协议对接、应用注册与属性映射、联调上线）、持续运维（目录维护、证书轮换、异常处置）。
- 估算前先固定范围：接入应用数、用户规模与账号类型、目录数量、建设期月数与运维期年数，范围不清会导致人天和费用口径漂移。
- 用可复算公式汇总：一次性投入＝（治理人天＋实施人天）×人日单价＋一次性费用；年度运维＝运维人天×人日单价＋周期性费用；三年TCO按年相加。
- 应用数量与异构程度、历史账号债务、外部账号比例是影响总投入最大的变量，建议对应用数和治理人天做低中高三档敏感性分析。
- 人日单价、税费和示例金额均按假设列示，具体价格、协议兼容版本与认证结论需向厂商查证后再写入立项材料。
接入范围与时间跨度怎么界定
估算的第一步是把边界写清楚。范围不清，后续的人天和费用都会随口径漂移。建议在立项材料中固定五项数据：接入应用数、覆盖用户数、目录数量、建设期月数、运维期年数，并由项目负责人签字确认后作为估算基线。
接入应用清单要分层列出。第一层是研发平台本体，即需要SSO登录的主系统；第二层是与之强关联的工具，例如代码托管、持续集成、制品库、缺陷跟踪；第三层是内部管理系统，例如工时、报销、门户。每层标注优先级：P0为上线必须完成，P1为上线后三个月内完成，P2为后续规划。应用数量直接决定应用注册、属性映射和联调的工作量。
用户规模要区分账号类型。正式员工、外包人员、外部协作方在身份源、生命周期规则和审计要求上往往不同。外包账号可能来自独立目录或需要单独开通流程，外部协作方可能采用邀请制或临时账号，这些都会增加治理和运维的工作量。统计时按类型分别给出人数，而不是只给一个总数。
目录来源要盘清。常见的是LDAP、Microsoft AD，也有企业使用HR系统作为权威源，或通过企业微信、钉钉等平台同步组织架构。目录数量指需要对接的身份源个数，两个以上目录就涉及身份合并与冲突处理规则。时间跨度上，建设期从需求确认到全量上线，通常按月计；运维期按年计，建议至少覆盖三年，便于计算TCO。
| 范围项 | 填写内容 | 用途 |
|---|---|---|
| 接入应用数 | P0/P1/P2分层数量 | 决定注册、映射、联调工作量 |
| 用户数 | 正式员工/外包/外部协作方分列 | 决定账号治理与支持量 |
| 目录数 | LDAP、AD、HR系统等身份源个数 | 决定同步开发与冲突处理 |
| 建设期 | 月数 | 决定人力投入节奏 |
| 运维期 | 年数（建议≥3年） | 决定TCO汇总区间 |
身份治理要投入哪些人力与动作
身份治理是容易被低估的一块。它发生在协议对接之前，产出的是干净的账号数据和明确的规则，没有这部分，SSO上线后会把历史问题原样带进新系统。治理工作主要由IT管理员、HR系统负责人、各业务系统管理员共同承担。
第一项动作是账号与组织架构梳理。导出各系统现有账号，与HR在职名单比对，识别离职未停用、重复开通、姓名工号不一致的账号，形成清理清单。工作量取决于历史账号债务，系统越多、存续越久，清理人天越高。第二项是确定唯一身份源和账号命名规则。明确以哪个目录为权威源，其他目录如何映射，工号、邮箱、手机号中哪个作为登录标识，重名和转岗场景如何处理。
第三项是账号生命周期规则设计。入职时账号如何自动创建、默认加入哪些组织、分配哪些基础角色；转岗时组织关系如何变更、旧权限如何回收；离职时停用时限是即时还是T+1，关联的外部账号如何处理。规则要写成可执行的判断条件，而不是原则性描述。第四项是目录数据质量核对与责任人指定。每个目录明确数据维护人，约定核对频率，例如每月抽查一次组织架构与在职名单的一致性。
| 工作项 | 主要角色 | 工作量估算（人天，示例） | 依赖 |
|---|---|---|---|
| 账号与组织架构梳理、重复账号清理 | IT管理员、各系统管理员 | 5–15 | 各系统账号导出权限 |
| 唯一身份源与命名规则确定 | IT负责人、HR | 2–5 | 管理层对权威源的确认 |
| 生命周期规则设计 | IT管理员、HR、安全 | 3–8 | 入职转岗离职流程现状 |
| 目录数据质量核对与责任人指定 | 目录维护人 | 2–5 | 目录管理权限 |
表中人天为示例区间，用于说明量级，实际取值应结合企业账号存量和流程复杂度调整。治理阶段的产出物包括账号清理清单、身份源说明、生命周期规则文档和目录责任人清单，这些文档也是后续实施和运维的输入。
在账号生命周期落地环节，如果研发平台侧需要承载组织同步与账号统一管理，ONES Account 支持对接 LDAP 协议服务与 Microsoft AD 服务，自动同步组织架构并验证登录；也支持从企业微信、钉钉同步账号与组织架构。对于非标准目录，可通过标准接口更新组织架构，这部分需要自行开发对接，工作量应计入实施预算。
实施成本包括哪些环节
实施阶段从协议选型开始，到全量上线和交接结束。它的投入集中在配置、联调和切换，工作对象是应用与身份源之间的信任关系。
协议选型决定对接方式。SAML适合与成熟的企业身份提供商对接，OIDC在移动端和现代应用中更常见，CAS在部分高校和传统系统中使用较多。选型时要确认研发平台支持哪些协议、身份提供商支持哪些协议，取交集后再评估属性映射的复杂度。ONES 支持 SSO 单点登录，可对接 CAS、SAML、飞书、企业微信、钉钉验证登录，具体协议组合与版本兼容性需向厂商确认。
应用注册与属性映射是实施的主体工作。每个接入应用需要在身份提供商侧注册，配置回调地址、证书，定义用户名、邮箱、部门、角色等属性的映射规则。角色映射往往比用户属性更费时，因为各系统的角色体系不一致，需要逐一对照。测试联调包括单点登录、单点登出、会话超时、异常账号等场景，灰度阶段先选少量用户验证，再分批放量。上线切换要准备回退方案，保留原登录方式一段时间作为过渡。文档、培训和交接包括配置说明、运维手册和故障处置流程。
| 实施环节 | 主要工作 | 人天估算（示例） | 前置条件 |
|---|---|---|---|
| 协议选型与方案确认 | 协议比对、兼容性确认 | 2–4 | 应用清单与身份源确定 |
| 应用注册与属性映射 | 逐应用配置、角色对照 | 每应用1–3 | 治理阶段规则文档 |
| 测试联调与灰度 | 场景测试、分批放量 | 5–10 | 测试环境与测试账号 |
| 上线切换与回退准备 | 切换执行、回退预案 | 2–5 | 灰度验证通过 |
| 文档、培训与交接 | 运维手册、管理员培训 | 2–4 | 配置定稿 |
应用注册与属性映射按应用数累加，是实施成本中最容易随范围扩大的部分。若接入应用数量为10个，仅这一项就可能达到10–30人天。表中数值为示例假设，用于建立估算模型，不代表任何厂商的实际报价或实施承诺。
口径与假设怎么定
在汇总金额之前，先把口径统一，否则不同人算出的总额无法比较。需要固定的口径包括币种、税费、人日单价、计费周期以及内外包差异。
币种与税费口径要写明是含税还是不含税，税率按企业实际适用税种处理。人日单价区分内部人力与外部服务：内部人力可按人力成本折算，也可只记录人天不折算金额；外部实施服务按供应商报价，需明确是否包含差旅和驻场费用。一次性费用与周期性费用分开列示，前者包括实施服务费、必要的软件许可或订阅首年费用，后者包括年度订阅、运维服务费和证书等。所有示例金额标注为假设，与厂商正式报价分开存放，避免在立项材料中混淆。
| 口径项 | 取值说明 | 数据来源类型 |
|---|---|---|
| 币种 | 人民币，全文统一 | 假设 |
| 税费 | 注明含税/不含税，税率按企业适用 | 待财务确认 |
| 内部人日单价 | 按人力成本折算，示例值仅用于演示公式 | 假设 |
| 外部人日单价 | 以供应商报价为准 | 待查证 |
| 计费周期 | 一次性费用与年度费用分列 | 假设 |
| 内外包划分 | 治理与联调以内部为主，实施服务可外包 | 假设 |
总体投入的计算模型与预算框架
把三块成本合成总投入，用两个公式即可复算。一次性投入＝（治理人天＋实施人天）×人日单价＋一次性费用。年度运维＝运维人天×人日单价＋周期性费用。三年TCO＝一次性投入＋年度运维×3，若各年运维工作量不同，按年分别计算后相加。
运维人天包括目录与账号变更维护、证书与密钥轮换、异常登录处置和定期核对。证书轮换通常每年一次，异常处置按工单量估算，定期核对按目录数量乘以核对频率。预算表按统一字段组织，便于逐项复核和调整。
| 项目 | 单位 | 数量 | 单价 | 小计 | 备注 |
|---|---|---|---|---|---|
| 身份治理人力 | 人天 | 示例12 | 示例单价 | 数量×单价 | 含账号清理与规则设计 |
| 实施人力 | 人天 | 示例30 | 示例单价 | 数量×单价 | 按应用数累加 |
| 一次性费用 | 项 | 1 | 待厂商报价 | 按报价 | 实施服务或许可 |
| 年度运维人力 | 人天/年 | 示例10 | 示例单价 | 数量×单价 | 含轮换与异常处置 |
| 周期性费用 | 年 | 3 | 待厂商报价 | 按报价×年数 | 订阅或运维服务 |
表中数量为示例假设，用于演示计算过程。实际立项时，把示例值替换为经责任人确认的取值，单价一栏区分内部折算价与厂商报价，待查证项在备注中标注。
哪些因素会让投入明显变化
同样的用户规模，不同企业的SSO投入可能相差数倍，差异主要来自以下几个变量。立项时对这些变量做区间估算，比给一个精确数字更有参考价值。
- 接入应用数量与异构程度：应用越多、技术栈越杂，注册、映射和联调的人天越高，影响方向为正，量级可达实施人力的主要部分。
- 目录数据质量与历史账号债务：重复账号和离职未停用账号越多，治理阶段清理人天越高，影响方向为正。
- 用户规模与外部账号比例：外部协作方账号往往需要单独的开通与回收流程，比例越高，治理和运维工作量越大。
- 自建与采购方案差异：自建需要投入开发与长期维护人力，采购需要支付订阅或服务费，两者在一次性与周期性费用上的分布不同，需按同一时间跨度比较。
- 合规与审计要求：需要留存登录日志、定期出具账号核对报告的场景，会增加运维人天和工具投入。
建议对应用数量和治理人天两个变量做敏感性分析，分别按低、中、高三档取值，观察总投入的变化区间，作为预算上下限的依据。
取数方法与立项核对
估算中的每个数字都应有来源和确认人。应用数量从应用台账或CMDB取，用户规模从HR系统取，目录信息从目录服务管理员处取，内部工时从历史项目记录或团队排期取，外部报价向厂商索取并附实施范围说明。
向厂商索取报价时，要求写明实施范围、包含的应用数量、是否含联调与培训、服务期限和响应时限，避免报价口径与内部估算不一致。内部工时按角色分别记录，便于后续复盘。立项前按下表逐项核对，确认范围、口径、假设和责任人四项均已落实。
| 核对项 | 核对内容 | 确认人 |
|---|---|---|
| 范围 | 应用清单、用户数、目录数、建设期与运维期 | 项目负责人 |
| 口径 | 币种、税费、人日单价、一次性与周期性划分 | 财务与IT负责人 |
| 假设 | 示例值是否已替换、待查证项是否标注 | 估算编制人 |
| 责任人 | 治理、实施、运维各环节的负责人 | 项目负责人 |
完成核对后，预算表即可作为立项材料提交。后续若接入范围调整，按同一公式更新数量与单价，保持估算过程可追溯。
常见问题
只有一个AD目录、接入应用也不多，身份治理还需要单独投入吗？
需要，但工作量可以压缩。即使只有一个AD目录，仍要确认它是否为权威身份源、工号或邮箱哪个作为登录标识、离职账号的停用时限，以及各应用现有账号与AD名单是否一致。目录数量少主要降低的是同步开发和冲突处理的工作量，账号清理与规则设计这两项动作依然存在。
实际操作中，可以先做一次账号比对，把离职未停用、重复开通的账号列成清单，再评估清理所需人天。若历史账号债务很小，治理阶段可以控制在较低人天区间，但仍建议把规则文档写出来，作为实施和后续运维的输入。
外包和外部协作方账号，在SSO接入中会额外增加哪些工作？
外部账号通常不在HR主名单内，身份源、开通流程和回收时限都与正式员工不同。常见额外工作包括：为外部账号确定独立的目录或邀请制开通方式，设计到期自动停用规则，以及在审计时能区分内部与外部账号的登录记录。
估算时按账号类型分别统计人数，外部账号比例越高，治理阶段的规则设计和运维阶段的账号回收工作量越大。如果外部协作方数量很少，也可以先沿用人工开通、定期核对的方式，把自动化留到后续阶段，相应降低一次性投入。
自建SSO和采购现成方案，成本结构上怎么比较？
两者要在同一时间跨度下比较。自建的主要投入是开发人力、长期维护人力和服务器资源，一次性开发费用较高，后续每年仍有维护和升级工作量；采购方案的主要投入是订阅或服务费加上实施配置人力，一次性费用相对低，周期性费用更明显。
比较时把两块都折算到三年TCO：自建按开发人天加三年维护人天计算，采购按首年实施加三年订阅费用计算，再叠加各自的内部治理人天。注意自建方案中协议兼容、证书轮换和安全补丁的长期投入容易被漏算，采购方案中超出约定应用数量的增补费用也要问清。
接入范围在上线后扩大，预算怎么跟着调整？
按同一套公式更新数量即可。新增应用主要增加应用注册与属性映射人天，按每应用1–3人天的示例区间累加，同时增加联调工作量；若新增应用来自新的目录或新的账号类型，还要补充治理和运维人天。
建议在立项预算中预留一块范围调整余量，并在预算表备注中写明余量用途。每次范围变更后更新应用清单和预算表，保留版本记录，便于后续复盘实际投入与估算的偏差。
立项材料里，哪些数字必须标注为待查证？
凡是来自厂商而非内部确认的数字，都应标注待查证，包括软件订阅价格、实施服务报价、协议兼容版本和认证结论。内部人日单价若按人力成本折算，也应注明折算方法和假设。
待查证项在预算表中单独列出，与已确认的范围数据分开存放，避免在评审时被当成确定报价。向厂商索取报价时，要求写明实施范围、包含的应用数量、是否含联调与培训、服务期限，便于与内部估算口径对齐。
