研发平台接入SSO的预算，通常要按“一次性建设投入+周期性运维投入”两段来算，时间跨度建议取3年，便于把首年采购和后续续费放在同一张表里比较。核算边界先限定在身份认证与账号、组织架构同步、LDAP/AD目录对接和研发平台侧SSO接入，访问授权策略、知识文档权限、消息通知不计入本框架。下面给出一套可复算的TCO结构，示例金额均标注为假设值，实际报价以厂商书面文件为准。
要点总览（TL;DR）
- SSO项目预算按“一次性建设投入+3年运维投入”两段核算，范围限定在身份认证与账号、组织架构同步、LDAP/AD目录对接和研发平台侧接入。
- 成本清单要区分资金支出与人力投入，逐项标注单位与承担角色，证书域名、测试环境、培训、历史账号清理这些小额项不要漏。
- 估算前先统一币种税费、计费周期、账号口径和人力单价，示例金额与厂商书面报价分表列示，未取得报价的项写为假设值。
- 用三个公式复算：一次性投入、年度运维投入、三年TCO，再分摊到单应用和单账号，便于横向比较和向决策层解释。
- 敏感因素按账号规模与计费模式、应用数量与异构程度、身份源复杂度、人力单价与自动化程度排序，对影响最大的一项做区间测算。
估算范围与时间跨度怎么定
SSO项目的成本边界如果一开始不划清，预算很容易被相邻议题撑大。建议在立项文档里先写一张范围表，把纳入项、排除项、时间窗口和规模参数固定下来，后续所有报价和工时都挂在这张表上。
| 类别 | 内容 | 说明 |
|---|---|---|
| 纳入范围 | 身份认证与账号管理 | 登录认证、账号创建与停用、账号与人员对应关系 |
| 纳入范围 | 组织架构同步 | 部门、岗位、人员归属关系的自动同步 |
| 纳入范围 | LDAP/AD目录对接 | 目录服务连接、同步规则、登录验证 |
| 纳入范围 | 研发平台侧SSO接入 | 研发平台作为服务提供方完成协议对接与登录改造 |
| 排除范围 | 访问授权策略 | 角色权限、项目权限、数据权限的规则设计 |
| 排除范围 | 知识文档权限 | 文档空间、知识库的共享与访问控制 |
| 排除范围 | 消息通知机制 | 登录提醒、账号变更通知等触达渠道 |
时间跨度建议拆成“一次性建设期”和“3年运维期”。建设期从身份源梳理开始，到切换上线并通过验收结束，通常按周或按月排期；运维期从上线次月起算，覆盖许可续费、对接维护、账号运营和故障处置。选择3年是因为多数订阅合同按年签署，3年足以体现续费累积效应，也方便与同类项目横向比较；如果合同期是1年或5年，把公式中的年数替换即可。
规模用三个参数描述：接入应用数量（研发平台内需要走SSO的子系统或工具数量）、账号规模（需要纳入统一认证的人员账号数）、身份源数量（LDAP、AD、企业微信、钉钉等目录或身份提供方的个数）。这三个参数直接决定许可费用和实施人天，应在范围表中写明取数时点和数据来源。
SSO项目包含哪些成本和资源项
把总投入拆成可逐项取数的清单，是后续计算的前提。清单要区分资金支出和人力投入，每项标注单位与承担角色，避免把内部工时和厂商服务费混在一起。
| 阶段 | 成本项 | 单位 | 承担角色 |
|---|---|---|---|
| 一次性 | 身份平台采购或订阅首年费 | 套/年 | IT采购 |
| 一次性 | 实施服务费（对接配置、联调） | 人天 | 厂商实施顾问 |
| 一次性 | 目录同步与SSO对接配置 | 人天 | 身份管理员、应用侧开发 |
| 一次性 | 测试与切换（含回退预案演练） | 人天 | IT运维、应用侧开发 |
| 一次性 | 历史账号清理与数据核对 | 人天 | 身份管理员 |
| 一次性 | 证书、域名、测试环境 | 项/年 | IT运维 |
| 一次性 | 管理员与应用方培训 | 场/人天 | 身份管理员 |
| 周期性 | 许可续费或订阅 | 年 | IT采购 |
| 周期性 | 对接维护（协议升级、应用新增） | 人天/年 | 应用侧开发 |
| 周期性 | 账号生命周期运营（入职、转岗、离职） | 人天/年 | 身份管理员 |
| 周期性 | 审计与合规评审 | 人天/年 | 安全与合规 |
| 周期性 | 故障处置与值班支持 | 人天/年 | IT运维 |
易被漏算的几项值得单独提醒：证书到期更换和域名备案的隐性工时、测试环境与生产环境的资源占用、上线前的管理员培训、历史遗留账号的清理工作量。这些项金额不大，但漏掉会让预算在实施阶段出现缺口。人力项要区分内部人天和外部服务人天，前者按内部成本口径折算，后者按合同单价计。
口径与假设怎么统一
不同方案能否横向比较，取决于口径是否一致。建议在预算表前附一页假设说明，逐条列出取值、来源状态（已确认或假设），后续所有计算都引用这张表。
| 口径项 | 建议取值方式 | 来源状态 |
|---|---|---|
| 币种与税费 | 统一人民币，注明含税或不含税，税率单列 | 按财务要求确认 |
| 计费周期 | 一次性费用、按年订阅、按账号或按应用计费分别列示 | 以厂商报价条款为准 |
| 账号口径 | 明确是全员账号、仅研发账号还是活跃账号 | 从账号系统盘点 |
| 人力单价 | 内部人天成本与外部服务人天单价分开 | 内部按薪酬口径估算，外部按合同 |
| 示例金额 | 标注“假设值”，与厂商现价分表列示 | 假设 |
账号口径尤其容易产生分歧：按全员账号计费时，研发平台只服务部分人员，但许可可能覆盖全公司；按活跃账号计费时，需要定义活跃的统计周期。这个口径直接改变许可费用量级，必须在询价阶段与厂商书面确认。人力单价方面，内部人天成本通常按岗位薪酬加管理分摊折算，外部服务人天按合同报价，两者不能简单相加成一个“人天单价”。
总体投入怎么算：计算模型与预算框架
在范围和口径确定后，用三个公式即可复算。一次性投入、年度运维投入和三年TCO分别计算，再把结果分摊到单应用和单账号，便于向不同决策层解释。
- 一次性投入 = 平台首年费 + 实施人天 × 外部人天单价 + 内部对接工时 × 内部人天成本
- 年度运维投入 = 许可年费 + 运维人天 × 人天单价 + 账号运营工时 × 内部人天成本
- 三年TCO = 一次性投入 + 3 × 年度运维投入（年限可按合同期调整）
下面是一个带假设数值的算例，所有金额均为示例假设，不代表任何厂商现价。假设接入应用20个、账号规模2000个、身份源2个（AD加企业微信），外部人天单价按1500元、内部人天成本按800元计。
| 项目 | 数量 | 单价假设 | 金额（元） |
|---|---|---|---|
| 平台首年费 | 1套 | 假设120000 | 120000 |
| 实施服务 | 25人天 | 1500 | 37500 |
| 内部对接工时 | 30人天 | 800 | 24000 |
| 一次性小计 | — | — | 181500 |
| 许可年费 | 1年 | 假设120000 | 120000 |
| 运维与对接维护 | 15人天/年 | 1500 | 22500 |
| 账号运营与故障处置 | 20人天/年 | 800 | 16000 |
| 年度运维小计 | — | — | 158500 |
| 三年TCO | — | — | 657000 |
按上表，单应用分摊约32850元，单账号分摊约328.5元。这两个数字的意义在于比较：当应用数量翻倍而账号不变时，单应用成本下降；当账号规模翻倍时，许可费用可能按比例上升，单账号成本变化取决于计费模式。把分摊结果和敏感性分析放在一起看，比只看总额更有决策价值。
在运维阶段，账号生命周期运营和对接任务往往散落在邮件和表格里，工时难以归集。ONES 支持从企业微信、钉钉同步账号与组织架构，也支持对接 LDAP 协议服务和 Microsoft AD 服务，实现组织架构自动同步与登录验证；SSO 方面可对接 CAS、SAML、飞书、企业微信、钉钉验证登录。对于非标准目录，可通过标准接口更新组织架构。这些能力可以减少手工同步和重复对接的工时，在成本表中体现为账号运营人天的下降。把入转离流程、应用接入申请和故障处理放进统一的工作项跟踪，也有助于下一轮预算时按实际工时取数，而不是凭印象估算。
哪些因素最影响总投入
敏感因素排序的目的，是让立项团队把有限的核实精力放在影响最大的变量上。按经验，影响从大到小大致是：账号规模与计费模式、接入应用数量与异构程度、身份源复杂度、人力单价与自动化程度。
| 敏感因素 | 影响方式 | 验证动作 |
|---|---|---|
| 账号规模与计费模式 | 按账号计费时许可费用随规模线性变化；按应用计费时受应用数量驱动 | 向厂商索取两种计费模式的书面报价，按当前和三年后账号数各算一次 |
| 接入应用数量与异构程度 | 标准协议应用对接快，自研或老旧系统改造工时长 | 盘点应用清单，按协议类型分组，抽取2至3个典型应用做对接工时估算 |
| 身份源复杂度 | 多目录并行、组织架构规则不一致会增加同步配置和核对工作量 | 梳理目录清单与字段映射差异，请实施方给出配置人天 |
| 人力单价与自动化程度 | 长期成本中人力占比高，自动化程度决定运营人天 | 用历史项目工时校准内部人天，评估自动同步和自助改密可减少的工单量 |
排序之后建议做一次区间测算：对每个敏感因素取低、中、高三档，观察TCO变化幅度。变化幅度最大的那一项，就是谈判和方案设计时最该投入精力的地方。例如账号规模对许可费用影响显著时，可以讨论分阶段纳入账号，先覆盖研发人员再逐步扩展。
数据从哪里取、怎么核验
预算的可信度取决于每项数据的来源是否可追溯。建议为每个成本项记录取数来源、取数时间和状态，状态分为已确认、估算、待确认三类，待确认项在预算表中单独标注，不用确定语气写入总额。
| 数据项 | 取数来源 | 核验方式 |
|---|---|---|
| 厂商报价与许可条款 | 供应商书面报价单、合同条款 | 核对报价有效期、计费口径、税费与续费涨幅条款 |
| 内部人力工时 | 历史同类项目工时记录、排期计划 | 与项目负责人交叉确认，标注估算依据 |
| 账号与应用数量 | 现有账号系统导出、应用清单盘点 | 与业务方核对口径，确认统计时点 |
| 证书、域名、环境费用 | 运维台账、云资源账单 | 按年化金额计入，注明是否含在平台费用内 |
| 培训与切换成本 | 培训计划、切换方案 | 按场次和人天估算，标注为估算值 |
核验时重点做三件事：一是报价口径对齐，确认厂商报的是首年费还是年均费、含税还是不含税、是否包含实施；二是与同类项目对比，用其他团队已完成的SSO项目单应用实施人天作为参照；三是设定复核节点，在合同签署前和上线验收后各复核一次实际支出与预算的偏差，把偏差原因记录下来，作为下一轮估算的依据。未取得书面报价的项，在预算表中写为假设值并注明“待厂商确认”，避免把假设当成确定价格向上申报。
常见问题
账号规模在立项后还会增长，预算要不要按三年后的规模算？
建议同时算两个口径：按当前账号数算一版，按三年后预计账号数算一版，两版都写进预算表。按账号计费时，许可费用随规模变化，只按当前规模申报容易在第二年续费时出现缺口；按应用计费时，账号增长对许可影响较小，但账号运营人天仍会上升。两版之间的差额可以作为分阶段纳入账号的谈判依据，例如先覆盖研发人员，再逐步扩展到其他部门。
身份源同时有AD、LDAP和钉钉，实施工作量会明显增加吗？
多身份源并行会增加同步规则配置、字段映射核对和账号去重的工作量，具体人天取决于各目录的组织架构规则是否一致。立项时可以请实施方按“每个身份源单独配置+跨源账号匹配”拆分工时，并抽取一个部门做小范围同步验证，用实际结果校准总人天。ONES 支持对接 LDAP 协议服务与 Microsoft AD 服务，也支持从企业微信、钉钉同步账号与组织架构，非标准目录可通过标准接口更新组织架构，这些能力可以减少手工同步环节，但多源匹配规则仍需在实施中确认。
厂商报价里没有单列实施服务费，预算怎么处理？
先向厂商索取书面报价，明确报价包含的范围：是否含对接配置、联调、培训和上线支持，是否含税，续费涨幅条款如何约定。报价未单列实施费时，不要默认实施已包含，应在预算表中把实施人天按假设值单列，并标注“待厂商确认”。同时用同类项目已完成的SSO实施人天作为参照，交叉核对量级是否合理。
上线后运维成本怎么持续跟踪，避免下一轮预算凭印象估？
把账号入转离处理、应用接入申请、协议升级和故障处置都记录成可统计的工单或工作项，按季度汇总实际投入人天，与预算中的运维人天对比。偏差较大的项要记录原因，例如新增应用数量超出预期或目录规则调整。ONES 的工作项与流程管理可用于跟踪这类对接和运营任务，下一轮预算时按实际工时取数，比凭印象估算更可靠。
三年TCO算出来之后，怎么判断这个投入是否合理？
单看总额难以判断，建议做三个对比：一是分摊到单应用和单账号，与同类项目的分摊值比较；二是对敏感因素取低、中、高三档做区间测算，看TCO波动范围是否在可接受区间；三是把一次性投入与三年运维投入的比例列出来，运维占比过高时，优先评估自动同步、自助改密等减少人工工单的措施。对比结论写进立项材料，比只报一个总额更有说服力。
