很多企业讨论 AI 落地时，会很快走向两个极端：要么给员工增加一个聊天入口，要么认为必须先完成核心系统重构，AI 才有条件进入生产。
10 月 7 日，IBM 与美国医疗系统 Providence 公布的一项实践，提供了第三种思路：不先替换核心系统，而是围绕一条真实业务旅程，重组系统之间的数据、任务和审批。
Providence 拥有约 11.9 万名员工。其招聘经理需要在多个系统间操作、等待人工审批，内部员工调岗也面临复杂流程。更值得注意的是，Providence 近一半的年度招聘活动来自内部流动，但流程一度复杂到部分员工认为“离职后以外部候选人重新申请”反而更容易。
这不是单纯的界面问题。它说明企业可能正在持续支付一种不容易出现在财务报表里的成本：员工为了完成同一件事，反复寻找入口、搬运信息、确认状态、催促审批，并承担系统之间口径不一致带来的返工。我们可以把它称为跨系统工作税。
Providence 与 IBM 构建的 RITA（Requisition and Internal Transfer Agent）没有取代现有的 Oracle Fusion Cloud HCM 与招聘环境，而是在现有系统及其他数据源之上协调职位申请、审批、内部调岗、职位推广和进度更新。IBM 披露，项目使招聘经理的行政工作量减少 90%，内部员工平均提前 12 天进入新岗位，调岗成本降低 60%，流程准确率最高提升 70%。
这些数字仍需要谨慎理解，但案例揭示的方向很清楚：企业 AI 的一个高价值入口，并不是“再造一个会回答问题的工具”，而是减少完成一项业务结果所需的组织摩擦。
真正需要改造的，不一定是系统，而是工作穿过系统的方式
传统信息化通常按职能和记录对象建设系统：人力系统管理员工，招聘系统管理职位和候选人，财务系统管理成本，工单系统管理请求。每个系统都可能运行正常，但一条真实业务旅程往往横跨多个系统、团队和审批权。
问题因此不只是“数据分散”，而是以下几件事同时分散：
如果只是把 AI 放在这些系统前面，提供一个自然语言入口，复杂性并不会自动消失。AI 可能只是替用户更快地穿行于旧流程，甚至把原本可见的矛盾隐藏在顺滑对话之后。
因此，建设跨系统 Agent 前，企业首先要回答一个问题：我们是在自动化一条已经合理的流程，还是在用自动化固化历史遗留的政策、审批和职责重叠？
- 当前事实在哪里，例如岗位、员工资格、预算和组织关系；
- 下一步动作由谁发起、由谁批准；
- 哪些规则可以自动判断，哪些必须人工裁量；
- 流程停滞时由谁接手；
- 什么状态才算真正完成，而不是仅在某个系统中关闭。
不要把所有摩擦都当成“低效”
审批、复核和等待并不天然应该被删除。有些步骤用于控制预算，有些用于保障劳动者权益，有些是高后果决定前必要的专业判断。真正的流程改造，需要把摩擦分成至少四类：
前两类往往可以积极自动化；第三类需要业务治理先于模型；第四类不能因为 AI 能生成建议，就被悄悄降级为形式化确认。
这一区分尤其适用于招聘和内部流动。流程可以自动准备材料、校验必填项、提示缺失信息并协调状态，但涉及候选人评价、资格例外、薪酬、晋升与录用的决定，仍需要明确谁在依据什么信息承担责任。
美国国家标准与技术研究院（NIST）的 AI 风险管理框架也强调，应根据具体场景界定系统范围，记录人类监督流程，并评估对个人和群体的正面、负面及意外影响。美国劳工部发布的 AI 与包容性招聘框架则提醒，用于招聘的 AI 技术可能给残障求职者带来无意的歧视和无障碍障碍。
换言之，减少无价值的操作，不等于减少必要的判断。
- 摩擦类型：典型表现：适合的处理方式
- 导航摩擦：不知道去哪个系统、找哪个入口：统一交互与任务编排
- 搬运摩擦：重复录入、复制材料、查询状态：受控读取、字段校验与系统写回
- 规则摩擦：相同事项在不同团队使用不同口径：明确规则版本、适用范围与责任人
- 控制摩擦：预算、资格、公平性或例外事项需要复核：保留人工判断、证据与升级路径
让 Agent 接管任务之前，先建立“任务契约”
企业要把这种模式安全地复制到采购、客服、项目交付、财务共享或供应链流程中，可以先为每一种跨系统任务定义一份任务契约，而不是从“做一个通用 Agent”开始。
一份可执行的任务契约至少应包含：
有了任务契约，Agent 才不只是一个跨系统“代点鼠标”的机器人，而是被限定在明确事实、权限和责任边界内的流程参与者。
- 业务结果：最终要实现什么，例如“员工已按确认日期进入新岗位”，而不是“完成一次表单提交”。
- 事实来源：哪些系统分别是岗位、人员、预算和审批状态的权威来源，发生冲突时以谁为准。
- 动作权限：AI 可以读取、准备、提交、提醒还是写回；不同动作是否需要不同授权。
- 规则版本：使用哪一版政策，适用于哪些地区、岗位、组织和时间区间。
- 人工责任：哪些判断必须由具备相应职责的人完成，AI 应向其展示哪些原始依据和异常。
- 例外出口：数据缺失、规则冲突、系统不可用或当事人提出异议时，任务如何暂停、转交和恢复。
- 完成证据：哪个系统状态、哪位责任人的确认以及什么业务结果共同证明任务闭环。
验收时，不要只看节省了多少分钟
Providence 案例的价值，在于它同时披露了行政工作量、到岗时间、成本和准确率，而不是只报告交互次数或生成速度。这也提示企业，跨系统 AI 至少要从四个层面验收：
还应同时观察一个反向指标：流程变快以后，人工是否拥有足够时间处理真正复杂的例外。如果平均周期下降，却出现更多错误写回、审批人盲目确认、员工无法纠正信息或异常长期无人接管，那么速度只是把成本转移到了下游。
- 工作量：重复录入、人工查询、催办和纠错减少了多少；
- 周转结果：从业务请求发起到真正完成，端到端时间缩短了多少；
- 例外质量：异常是否被正确识别并交给合适的人，而不是被系统静默绕过；
- 人员结果：不同群体的完成率、等待时间、退出率、申诉和纠正情况是否出现不合理差异。
对准备推进 AI 的企业，起点可以更具体
企业不必先寻找“最先进的 Agent 场景”，也不必把所有核心系统一次性推倒重来。可以先选择一条具备以下特征的业务旅程：业务结果明确、跨越多个系统、重复协调成本高、异常可以识别、现有责任人清楚，并且能够获得上线前后的基线数据。
用两到四周还原真实流程，而不是只阅读制度文件：观察员工在哪些环节反复切换系统，哪些字段需要重新解释，哪些审批只是在补偿上游信息不足，哪些例外依赖少数人的经验。随后先删除不必要步骤，再决定哪些环节适合自动读取、准备、路由、提醒或写回。
这样的项目可能没有“全面替换核心系统”宏大，却更容易建立可信的价值闭环：员工少做了什么无效工作，业务结果提前了多少，哪些风险仍由谁控制，出了问题如何恢复，都能被清楚说明。
案例边界：亮眼结果不等于普遍规律
本文引用的 90% 行政工作量减少、平均提前 12 天到岗、60% 调岗成本下降和最高 70% 准确率提升，均来自 IBM 与客户的联合披露。公开材料没有给出各指标的完整定义、样本量、测量周期、基线绝对值、分群结果、项目总成本或独立审计，因此不能直接外推为其他企业的预期收益。
公开材料也没有说明 AI 是否参与候选人排序、评价或录用决定。本文不据此推断 RITA 具备自主招聘决策能力，更不把流程效率改善等同于公平性、员工留任或患者服务结果已经得到证明。
真正可复制的不是某个产品名称，而是一种实施顺序：以业务旅程为单位识别跨系统工作税，先厘清事实、规则、权限与例外，再让 AI 承担适合自动化的协调工作，并用端到端结果和人员影响共同验收。
企业级 AI 的专业性，最终不体现在它能连接多少系统，而在于连接之后，工作是否更简单、责任是否更清楚、结果是否更值得信任。
