跨部门依赖太多的 AI 场景，应该拆小、延后还是放弃？

企业最有价值的 AI 场景，往往也最难推动：销售等产品资料，产品等研发确认，研发等数据权限，最后还要经过法务、财务和安全。

整条链一次性交给 AI，项目很容易卡死。只做一个无关痛痒的小功能，又无法证明业务价值。

跨部门场景要围绕一个可验收结果纵向切片，先跑通最短责任链，再根据证据扩大。 拆小、延后和放弃对应三种不同问题，不能混成一句“项目太复杂”。

先把依赖摊开

从任务触发画到结果交付，标明每一步的输入、输出、系统、负责人、等待时间和异常处理。再把依赖分成三类：缺少就无法完成结果的硬依赖；试点期可以人工补齐的临时依赖；只是沿用旧习惯、可以重设的惯性依赖。

很多“跨部门复杂”来自照搬旧流程。依赖被摊开以后，一部分重复审批和信息搬运可以直接删掉。

用三个问题决定去留

决定 适用情况 必须留下的下一步

拆小 价值明确，完整范围过大，但存在可 确认切片、负责人和扩围条件

验收闭环

延后 价值仍在，关键数据、接口、责任或 明确补什么、谁负责、何时复查

风险条件暂时缺失

放弃 价值靠假设，长期兜底成本过高，或 记录结论，处置已产出的资产

风险无法发现和控制

延后没有责任人和日期，通常只是礼貌搁置。放弃也要说明原因，避免几个月后换个名字重新立项。

怎样拆才不会拆成玩具

好的切片要保留真实输入、真实使用者和真实验收。例如，针对一类标准合同提取字段并生成风险提示，由法务确认。范围虽然小，仍完成了一个结果闭环。

只演示 AI 能读文档，没有人使用、没有写回动作、没有错误处理，这类切片无法证明流程能落地。

拆小的对象可以是文档类型、客户范围、动作权限或异常种类。业务结果必须保留，否则团队得到的只是技术演示。

保留终局图，只开放一段链路

有人担心切片会失去端到端价值。解决方式是保留完整终局流程图，同时只开放当前可控的一段。每扩大一步，都要求新增的数据、权限、责任和验收证据到位。

本篇重点处理跨部门依赖怎样切片。第 23 问会进一步讨论流程本身已经破损时，要先做多大程度的重构。

复杂场景的第一步，是找到最短的真实闭环。

本问行动：找一个卡住的项目，把所有依赖分成硬依赖、临时依赖和惯性依赖，再决定拆小、延后还是放弃。