第 10 章 · 共 15 章
系统、数据、权限与经营机制
10.1 系统架构与状态源
系统多不等于数字可信。每个字段只能有一个权威状态源:客户主体和商机在CRM,候选人招聘状态在ATS,人员关系与生效日在HRIS,考勤批准在考勤系统,工资计算在薪酬引擎,收入应收和现金在ERP。BI只做整合分析,不允许分析师直接在看板里改业务事实。
10.2 主数据与公共主键
| 主数据 | 权威系统 | 必要字段 | 变更控制 |
|---|---|---|---|
| 客户主体 | CRM/ERP | 法定名称、统一代码、信用、付款主体 | 法务/财务复核,禁止简称开票 |
| 合同项目 | 合同/项目系统 | 合同、版本、模式、地域、SLA、计费 | 变更单与版本生效日 |
| 职位 | ATS | 客户、画像、预算、状态、决策人 | 客户授权、项目经理批准 |
| 候选人 | ATS | 来源、授权、联系方式、状态、留存 | 更正、撤回、去重、访问日志 |
| 人员关系 | HRIS | 主体、关系类型、地点、生效、合同 | 授权材料与四眼复核 |
| 工单 | 工单系统 | 请求人、授权、类型、状态、回执 | 不允许无理由重开/关单 |
| 结算事件 | 项目/ERP | 验收、数量、价格、扣款、税务口径 | 客户签认与财务复核 |
10.3 候选人数据生命周期
【可核验事实|中国大陆】处理个人信息应有明确、合理目的并与目的直接相关,采取对个人权益影响最小的方式;敏感个人信息、向其他处理者提供、跨境等场景有更高要求。《个人信息保护法》(截至2026-08-10)
“加入人才库”不能变成无限期、无限客户、无限字段的概括许可。系统要能记录候选人从哪里来、何时被告知、为哪个机会同意推荐、共享给谁、对方是否继续使用、何时更新或删除。对于未录用人员,业务希望长期保留与个人希望停止联系之间要有可执行的选择和请求通道。
10.4 权限矩阵
| 数据/动作 | 销售 | 招聘顾问 | 项目经理 | 薪酬运营 | 财务 | 数据管理员 |
|---|---|---|---|---|---|---|
| 客户合同价格 | 读/申请 | 最小读取 | 读 | 无 | 读写结算 | 审计 |
| 候选人联系方式 | 默认无 | 按职位读写 | 汇总读 | 无 | 无 | 受控管理 |
| 候选人敏感材料 | 无 | 按必要性受控 | 审批后最小读取 | 无 | 无 | 加密与审计 |
| 客户员工主数据 | 无 | 无 | 汇总/例外 | 按工单读取 | 最小结算字段 | 权限管理 |
| 薪资明细 | 无 | 无 | 汇总 | 计算读写 | 付款所需最小字段 | 审计不改值 |
| 银行付款 | 无 | 无 | 申请/确认 | 制表不得最终付款 | 复核与授权 | 无 |
| 数据导出 | 禁止默认导出 | 限职位与水印 | 审批 | 受控批次 | 财务报表范围 | 审批、日志、DLP |
权限要随项目、职位和人员状态变化。销售赢单后不自动获得全部候选人;驻场人员离场当日回收客户和服务商账号;薪酬专员离开项目后不能继续看历史工资;临时批量导出必须有目的、字段、接收者、到期和删除任务。共享账号会让责任无法追溯,应作为高风险例外而非“现场方便”。
10.5 AI在招聘中的可用与不可用边界
AI可以帮助生成职位初稿、搜索同义词、摘要公开且有权使用的资料、发现缺字段、安排日程和辅助质检;不能未经验证自动编造候选人经历、把敏感属性推断成胜任力、以不可解释分数直接淘汰、绕过候选人同意批量抓取,或把客户和候选人数据输入未经批准的外部模型。
典型治理清单包括:明确使用场景、数据来源与授权、训练/提示输入边界、人工复核、偏差测试、输出标识、供应商合同、日志、申诉和停用机制。招聘决定影响个人机会,效率提升不能取消可解释的人工责任。
10.6 数据质量的五类校验
- 完整性:职位预算、候选人授权、人员生效日、银行账户是否缺失。
- 一致性:ATS到岗与客户HRIS是否一致,工单变更与薪酬结果是否一致。
- 唯一性:候选人、人员、合同和银行账户是否重复。
- 及时性:面试反馈、离职、考勤和工资变更是否在截止日前进入。
- 合理性:薪资环比、工时、服务量、退款、项目毛利是否超阈值。
质量异常不能直接在下游修数后结束。应定位权威源、修正源数据、重新跑接口、保留旧值与批准,并评估是否影响候选人、劳动者、客户账单、税费或财务报表。
10.7 业务连续性和灾备
发薪、批量到岗、校园招聘和大促客服等场景有明确时间窗。业务连续性计划要定义关键流程、最大可容忍中断、恢复目标、备用联系人、离线模板、付款双授权、数据恢复、供应商替代和演练频率。系统故障时可以用受控离线表维持必要动作,但恢复后必须回录、去重和对账,不能让离线副本永久散落。
10.8 经营驾驶舱
| 视角 | 核心问题 | 指标组合 | 决策 |
|---|---|---|---|
| 客户 | 需求真实且持续吗 | 活跃职位、冻结、反馈、续约、应收 | 深耕、调价、暂停或退出 |
| 供给 | 人才和团队够吗 | 授权人才、有效推荐、并发、上岗周期 | 招聘、培训或收窄 |
| 交付 | 流程稳定吗 | SLA、积压、等待、差错、保证期 | 改SOP、自动化、扩容 |
| 财务 | 赚到且收回了吗 | 项目贡献、应收、资金峰值、退款准备 | 信用、预付、奖金释放 |
| 权益风险 | 人和数据安全吗 | 投诉、工资事件、工时、安全、权限、泄露 | 停止、调查、补救、报告 |
| 组织 | 能复制吗 | 角色覆盖、单点依赖、离职、知识复用 | 继任、标准化、产品退出 |
10.9 三层会议机制
日会解决职位、工单、人员、安全和资金的红色阻塞;周会看漏斗、SLA、客户等待、产能和下周预测;月会把收入、贡献、应收、现金、投诉、保证期和权限放在一起。会议必须产出动作、负责人、截止日和验证指标,下一次先检查上次动作。没有动作的看板只是装饰。
10.10 经营诊断的证据优先级
当推荐数量突然增长,先看候选人同意、去重和客户接受,不先庆祝“产能提升”;当职位完成率上升,先看客户是否关闭了困难职位、状态是否回填;当事务工单正确率接近满分,先查未决项是否被关单、客户是否在系统外要求返工;当项目毛利改善,先核工资权益资金、分包成本、保证期准备和总部成本是否被移出项目。
证据优先顺序通常是原始交易和现场事实、受控单据与审计日志、跨系统勾稽、趋势与抽样、人员解释。解释不可缺少,但不能先用解释覆盖差异。诊断表应明确:观察到什么、口径是什么、可能原因、每个原因需要什么证据、谁在何时验证、结论若错误会造成什么决策损失。
例如“顾问效率下降”可能来自职位更难、客户反馈慢、薪酬竞争力差、顾问能力不足、系统状态不准或更多时间用于保证期替补。管理者先做职位难度和客户等待分层,再看顾问可控时间;若不分层便按人排名,容易惩罚承接困难职位的人,并鼓励团队挑简单单和藏失败。
10.11 从月报到可执行决策
月报第一页只保留七项:收入与贡献、收款与应收、交付结果、客户等待、人员/权益事件、数据权限、下月容量。第二页拆差异,第三页列风险和动作,其余明细可下钻。每个红色指标必须对应一个决策选项,例如“补人、减量、改SLA、调价、限信用、改模式或退出”,而不是笼统写“持续关注”。
经营会结束后,项目系统记录基线是否变化。若客户新增20个职位,收入预测、顾问容量、渠道预算、SLA和验收同步更新;若只在会议纪要写“加大支持”,下月的差异一定无法解释。动作关闭也要有验证:新增顾问不等于产能已改善,必须看到有效推荐和周期在不牺牲体验与保证期的前提下恢复。
图8:数据能力不是把所有信息集中给所有人,而是让必要的人在必要时做必要动作,并能完整追溯。
章末理解检查
合上原文,你能讲明白了吗?
不看原文,用自己的话解释「系统、数据、权限与经营机制」真正要解决什么业务问题。
已输入 0 个字,还需 12 个字;提交后会显示自检标准,并把本章记为已完成。