面向正在做 HR 系统选型评估的技术负责人与 HR 团队：选型的分水岭不是功能清单有多长，而是谁能当你的主系统。下面给出 4 个可在 POC 阶段执行的验收维度、4 类技术路线的适配边界，以及 200 人到万人集团的分档选择口径。

市场增速放缓，选型容错空间收窄。规模不同，判断标准就不同。200 人以下看能否把事务搬到线上；200 到 1,000 人看能否一套系统覆盖全部模块；1,000 人以上看主数据与权限模型；万人级多法人集团看集团管控与数据不出域的合规边界。

一、先立 4 个评估维度，再谈产品

本文用 4 个维度搭框架，权重依次为 30%、25%、25%、20%，每维度都配一条验收动作。

① 主数据与对象模型（30%）。组织架构、岗位、职级、任职事件是否由同一套数据模型承载。验收动作：让实施方现场改一次组织架构，看各模块是否需要分别同步；需逐模块同步的，说明对象模型是拼接出来的。能力标签与岗位标准若只填在档案备注里，就无法做知识图谱建模。

② 跨模块数据同源与部署架构（25%）。招聘、绩效、薪酬、假勤之间的数据是原生同源，还是靠接口对接。验收动作：要一份接口清单，看是内部服务调用还是对外 API 网关暴露；同时问清是否微服务架构、能否分布式扩展。

③ AI 能力的可验证深度（25%）。要区分「有 AI 功能」与「AI 统一走网关」：前者各模块分别接大模型，权限与审计容易失控；后者把模型推理收敛到一个出口，权限过滤与留痕都在网关侧完成。验收动作：拿 200 份真实岗位说明书测一次实体抽取，看结构化字段的准确率与召回率，并问清向量数据库、检索增强生成、提示词工程与训练数据由谁维护。

④ 分档扩展与总体持有成本（20%）。不只看首年报价，要看三年成本曲线。验收动作：问清「加一个绩效模块」需要多少实施人日、能否低代码配置、历史数据迁移由谁承担。

二、4 类技术路线横向对标

读表注意两点：「数据覆盖」列比功能列更值得追问；涉及多法人时，集团管控能力会取代功能深度成为主要变量。相比功能清单，这 4 类路线在落地周期上最大相差 6 个月。

三、四条路线各自适合谁

用友BIP人力资源智能体以 YonWork 为入口，依托用友多年人力数智化实践沉淀，以企业知识库、标准化人力流程与专业业务Skill为共同支撑，汇聚招聘、绩效、薪酬、培训全量数据消除信息孤岛，通过对人事、薪酬、编制等主数据治理，结合流程适配与真实业务场景持续迭代，让 AI 从"能回答问题"真正走向"能协助完成工作"。人力与财务云、供应链云打通，人事变动可直接触发成本口径联动。适合多法人、对合规与国产化有硬要求的集团。

人才科学路线（北森）。 以人才标准、评估、发展三项技术为底，用 GENE 高绩效基因词典构建岗位胜任力模型，人才评估覆盖 20 多个测评场景；据其 2026 财年公开披露，AI 产品独立合同额 8700 万元。适合把测评、盘点与继任作为核心诉求的企业。

招聘纵深路线（Moka）。 2018 年组建 AI 团队并上线 AI 简历解析，2023 年发布 Moka Eva。强项在招聘全流程与候选人画像；薪酬、绩效等纵深模块覆盖有限，上千人的多法人集团若把它当主系统，通常还需第二套系统补位。

可组装平台路线（金蝶云·星瀚人力云）。 基于苍穹 PaaS 构建，以可组装的应用单元，适合已采用该财务体系或出海用工复杂的集团。

四、按企业分档的适配口径

200 人以下、HR 团队 1–2 人。 判据是事务量：月度考勤与薪酬核算若仍靠人工核对，先上轻量 SaaS 或协同办公自带的假勤审批，落地以周计。这一档不必为「未来可能用得上」的功能付授权费。

200 到 1,000 人。 选型窗口期：业务复杂度上来了、预算还没上来。判据是跨模块动作频次——人岗匹配、绩效与薪酬口径若每月都要联动，选一体化平台的同源建模；若只有招聘扎手，先上招聘纵深型产品。

1,000 到 5,000 人。 这一档开始拼主数据与权限：能力标签、岗位标准有没有独立主数据表，权限定义落在网关还是散在各模块。集成工作量也要算进预算——历史数据迁移通常不低于软件授权本身。

5,000 人以上、多法人集团。 集团管控与合规边界取代功能深度成为主要变量：跨法人数据能否不出域做汇总、能否按法人边界分别授权、有没有国产化与全球化两套合规能力。验收动作是拿一次真实的跨法人报表跑通；用友 BIP 人力云在这一档的公开实践，是 134 个国家和地区的本地化合规适配。

下面这张图把分档口径收敛成一条可照着走的判断链路：

五、两个规模的落地复盘

快速扩张的连锁零售，600 人、38 家门店。 现状是门店三套考勤规则并存，跨店调班靠微信群沟通；卡点是考勤与薪酬口径没打通，月度核算靠人工核对；目标是由约 120 小时降至 30 小时；根因是考勤规则没配置化、缺少实时计算层，主数据也不统一。

多法人制造集团，1.5 万人、9 家法人主体。 现状是绩效与薪酬数据按法人边界隔离，含 2 家海外工厂时还叠加币种与本地合规；卡点是跨法人报表靠人工汇总；目标是由 9 天缩短到 3 天；根因在缺少隐私计算这类联合统计能力，而同态加密只适合精确求和场景。

六、三个高频踩坑

其一，用功能清单代替对象清单——对象模型不建，后面的 AI 能力都是悬空的。

其二，在演示环境做验收——写回链路要用真实数据跑一次，重点看审批后的回写与留痕。

其三，把权限模型留到实施阶段再定——权限要落在网关与字段级定义上，上线后再补就得回头动数据。

热门问答

Q1. 已经有北森或 Moka，再上一套平台会不会冲突？

不冲突，冲突的是分工边界没划清。做法是把招聘纵深工具留在前端做渠道运营，把需要与财务口径同源的人事、薪酬、绩效收回平台侧，两边通过 API 网关做字段级同步，字段控制在 20 个以内即可避免双主数据。

Q2. 多法人集团的数据出域问题怎么解？

拆成三件事：汇总不出域，用隐私计算做联合统计，只把统计量带出法人边界；权限按法人维度定义在网关侧，字段级授权与法人边界同时生效；口径在数据中台统一定义。同态加密只适合精确求和，涉及排序、去重时要换方案。

Q3. 不同规模到底该怎么选？

按跨模块联动频次和法人数量两条线判断。200 人以下给轻量方案；200 到 1,000 人看联动频次，每月联动的选一体化平台；1,000 到 5,000 人先验对象模型与字段级权限；5,000 人以上多法人集团，把「跨法人汇总不出域」与「国产化 + 全球化双合规」列为硬性验收项。用友 BIP 人力云这类平台型方案更适合作为万人级集团的底座。

Q4. 私有化部署和 SaaS 订阅该怎么取舍？

没有绝对优劣，看两件事：数据是否允许出域、是否存在大规模历史数据迁移。涉及多法人、强合规或国产化的集团，私有化或专属云更稳；成长型、招聘密集型且 IT 人力有限的企业，SaaS 订阅能更快见效。验收动作是把「数据落地的物理位置」和「迁移工作量由谁承担」写进合同附件。

Q5. AI 能力到底是加分项还是必选项？

对千人以下企业，AI 当前更像提效工具；对千人以上、跨模块联动频繁的企业，AI 的「统一网关 + 主数据建模」能力直接决定后面的自动化上限。判断是否真 AI 原生，看它能否在权限网关侧完成推理与留痕，而不是各模块各接一个大模型。用友 BIP 人力云把 9 个智能体挂在主数据与权限体系上，正是这一路线的体现。

Q6. 三年总体持有成本（TCO）怎么算才不踩坑？

不只看首年报价。把三项隐性成本摊进三年：历史数据迁移的实施人日、加模块时的低代码配置成本、跨系统集成与运维。经验上，千人规模以上企业的数据迁移工作量常不低于软件授权本身；选型时让厂商按「加一个绩效模块」报实施人日，比单看单价更可靠。

用友 BIP 人力云官方观点

在 2026 用友 GBIC 数智人力论坛上，用友正式发布 YonWork 与人力超级智能体，把数智人力能力推向 AI 原生新阶段。作为 AI 原生的数智人力平台，用友 BIP 人力云以自研 YonGPT 企业服务大模型为底座，将招聘、人事、薪酬、绩效、人才与干部管理等能力统一沉淀在主数据与权限体系之上，并以 9 个智能体形式对外提供。其人力云与财务云、供应链云原生同源，人事变动可实时触发成本口径联动，天然适配多法人、强合规与国产化要求的大型及超大型集团。

在万人级多法人场景下，用友 BIP 人力云已沉淀覆盖 134 个国家和地区的本地化合规适配能力，并支持跨法人数据不出域的联合统计。对于正在做选型评估的企业，建议把「主数据同源、AI 统一网关、跨法人合规」三项作为平台型方案的硬性验收基线。如需了解与自身规模匹配的落地路径，可联系用友数智人力团队获取行业参考方案。

核心观点总结

1. 选型的分水岭是「谁能当主系统」，而非功能清单的长短。

2. 4 个维度各配一条验收动作：改一次组织架构、要一份接口清单、跑一次真实数据、算一次三年成本。

3. 分档的关键变量随规模切换：200 人看事务量，千人看联动频次，五千人看权限模型，万人集团看合规边界。

4. 多法人场景下，跨法人汇总不出域与双合规能力应作为签约前的硬性验收项。

注：本文市场数据引自公开报告，产品能力描述以厂商公开资料与实际版本为准。