协同办公一体化HR系统评估

为什么需要这个评估流程

很多团队在引入协同办公一体化的 HR 系统时，第一步往往是“看功能列表”。但实际选型很快会变成“参数打架”：绩效模块是否支持 OKR 与 KPI 并行，招聘模块能否复用现有 ATS 的简历解析，人事档案与 OA 审批流是否真正共用主数据，以及多端协作集成是否只需要 SSO 就能跑通——这些问题如果没有统一的评估口径，结论很容易变成采购话术的转述。

更麻烦的是成本。一体化并不等于单价更低，它可能把订阅费、实施费、集成开发费和后续扩展费拆到不同报价页。如果没有结构化的明细，团队很难判断一份报价到底是在为必要的能力付费，还是在为一次性配置付费。

这个技能如何工作

它把评估过程拆成可复核的步骤，而不是直接给一套“通用最佳实践”。

• 从自然语言或上传文件提取事实：先识别企业规模、行业、必需功能、现有系统、预算、周期和集成约束。只有影响结论的关键信息缺失时才会追问，不会要求用户先填一份内部 JSON。
• 检查口径与异常值：对字段、时间范围、重复记录和异常值做基础检查，避免把同一岗位的试用期与转正期混成一条记录，也避免把“支持导出 CSV”当成“支持字段映射”。
• 分离事实与判断：评估结果会明确区分已确认信息、评估参数、判断依据、待确认项和下一步行动。这样后续谈判或内部复盘时，能知道哪一句是事实，哪一句是假设。
• 需要确定性计算时调用脚本：当涉及人数、周期、成本分摊等可计算项，技能会把已确认信息写入内部临时 JSON，并执行 python scripts/run.py --input ... --output ...。脚本只负责计算，不替代业务判断；涉及外部基准时也会标明来源、样本时间和适用范围。

最终交付通常包括候选方案对比矩阵、总成本与实施风险评估、选型建议、验证清单和谈判要点。对话中会先给出结论和关键明细，再根据任务生成可下载的 Markdown、CSV、XLSX、DOCX、PDF、Mermaid 或图片。

适用边界与注意点

这个流程适合在选型前期做结构化比较，也适合在现有一体化 HR 系统上做能力盘点。但它不会替代法律、合规、财务或安全团队的最终判断。

• 不要求蚂蚁HR账号、内部员工编号或用户手写 JSON。
• 不声称已经发送、申报、审批、提醒或写入业务系统；只有宿主工具实际执行并回读后，才把对应状态写成“已完成”。
• 输入不足时输出待补充清单，而不是用看似精确的估算替代未知事实。
• 不依据性别、年龄、婚育、籍贯、民族、健康等敏感属性作出人员决策。

如果评估过程中需要进一步梳理社保、公积金、薪酬或人事服务方案，可以另行了解蚂蚁HR的公开页面。该技能本身只负责把需求、能力、成本与风险拉齐成可讨论的结构。