第 4 章　业务发现：别急着选模型

4.1 客户说的需求，通常只是起点

客户可能说：“我们想做企业知识库”“希望用 AI 提高销售效率”“要建设一个智能客服”。这些话表达了方向，却还不是可以开发的需求。

如果立刻讨论模型、向量数据库或智能体框架，项目很容易做出正确的功能，却没有解决正确的问题。

业务发现的任务，是把一个宽泛愿望逐步还原为真实工作：谁遇到了什么困难，现在怎样处理，为什么处理不好，造成什么代价，改变之后怎样确认有效。

FDE 必须先成为问题的调查者，再成为方案的建造者。

4.2 区分愿望、症状、问题和结果

这四个层次经常被混在一起。

愿望是客户想做的方向，例如“用 AI 提升客服效率”。它能说明管理层的关注点，却不能直接决定系统形态。

症状是已经被观察到的现象，例如“客户等待时间太长”“新人经常答错”“每天有大量重复咨询”。症状比愿望具体，但可能由不同原因造成。

问题是造成症状的关键机制，例如信息分散、规则版本混乱、工单分派错误，或者必须等待少数专家确认。只有找到问题，才能判断该用流程调整、传统软件还是 AI。

结果是项目希望改变的可观察状态，例如缩短首次响应时间、降低转派率、提高一次解决率。结果必须与真实流程相连，而不是简单写成“完成系统上线”。

业务发现就是不断向下追问：这个愿望对应什么症状？症状由什么问题造成？如果解决，什么结果会改变？

4.3 看真实流程，不只看流程图

企业通常已经有制度文件和流程图，但“应该怎样做”与“每天怎样做”常常不同。

流程图可能写着客服从知识库查询答案，真实情况却是新人先在群里问老员工；制度规定合同经过标准审批，紧急订单却通过电话确认；系统显示某字段必填，大家可能一直填写同一个占位内容。

这些偏差并不一定是员工不规范。它们可能说明正式流程没有覆盖现实复杂性，人们只能创造临时办法让工作继续。

观察真实流程时，要特别留意：

• 工作从什么事件开始，到什么状态才算结束；
• 信息在哪些系统、文件和聊天工具之间移动；
• 哪些步骤需要等待，哪些步骤经常返工；
• 哪些决定有明确规则，哪些依赖个人经验；
• 出现例外时，员工怎样绕过标准流程；
• 哪些动作没有记录，却决定了最终结果。

FDE 不是为了纠正每一个“不规范动作”，而是理解它为什么存在。一个看似多余的人工确认，可能是在弥补数据缺失；一个私人表格，可能承载着核心系统没有支持的业务规则。

4.4 不同的人掌握不同的事实

只访谈一位负责人，几乎一定会得到不完整的答案。企业里的角色看到的是同一流程的不同切面。

决策者

决策者关心为什么现在要做、愿意投入多少资源、希望看到什么业务变化。他能提供战略方向和项目优先级，但通常不了解每一步实际操作。

流程负责人

流程负责人知道部门目标、上下游关系和主要矛盾，也清楚哪些变化会触及组织利益。他是推动试点的重要角色，但描述的流程可能更接近制度设计。

实际用户

实际用户知道工作怎样真正发生。他们清楚哪些数据不可靠、哪个按钮从来没人用、什么情况下必须找老员工。业务发现不能绕过他们。

IT 与安全人员

IT 人员掌握系统、接口、账号和运维现实；安全人员知道哪些数据能够使用，哪些操作必须审计。很多项目直到准备上线才找到他们，最终才发现原方案无法进入生产。

一次有效的业务发现，需要把这些事实拼在一起。不同说法互相矛盾时，不要急着判断谁对谁错，而要继续观察流程和数据。

4.5 找出企业里的“影子系统”

真正的业务知识往往不只存在于正式系统中。

Excel 里可能维护着客户等级和特殊价格；微信群里保存着故障处理经验；员工桌面的 Word 文档可能是最新操作手册；某位老员工记得十年前系统迁移留下的例外；一个每天手工复制的表格，可能连接着两个从未打通的平台。

这些内容可以统称为影子系统。它们看似零散，却维持着真实业务。

发现影子系统时，不能立即得出“全部导入知识库”的结论。先要判断：谁维护，多久更新，冲突时以谁为准，是否包含敏感信息，离开原作者后还能否解释。

AI 会放大输入中的混乱。未经治理的知识进入系统后，不会自动变成可靠知识，只会以更流畅的方式产生不一致答案。

4.6 把事实、判断和假设分开

业务讨论中最危险的情况，是把未经验证的判断当作事实。

“客服每天花很多时间查资料”是判断；“抽样 50 张工单，平均查找时间为 8 分钟”才是事实。“接入知识库后能节省一半时间”是预测；在小范围试用前，它只是假设。

FDE 可以用四种状态管理信息：

• 事实：已经由观察、数据或可靠记录确认；
• 判断：基于现有信息形成的解释；
• 假设：如果成立，方案才可能有效的前提；
• 待确认项：尚缺负责人、数据或验证方式的问题。

把四者分开，不是为了增加文档，而是避免团队在错误确定性上投入开发。项目早期最有价值的进展，往往不是多做一个页面，而是推翻一个错误假设。

4.7 找到真正能推动项目的人

企业项目很少由一个人决定。批准预算的人、管理流程的人、每天使用的人、掌握数据的人和负责验收的人可能完全不同。

FDE 需要识别几类关键角色：

• 发起者：为什么项目会出现；
• 业务负责人：对结果负责，能调动人员参与；
• 实际用户：决定系统是否会被使用；
• 技术与数据负责人：决定系统能否接入和运行；
• 风险否决者：安全、法务、合规或采购等能让项目停止的人；
• 验收者：最终根据什么标准判断项目完成。

其中最关键的是内部推动者。他不仅认可项目，还愿意协调数据、用户和跨部门资源，在遇到阻力时继续推动。如果一个项目只有外部供应商热情，没有客户内部负责人，通常很难进入生产。

也要尽早找到可能的否决者。绕过安全或 IT 也许能让演示更快，却会把阻力推迟到成本更高的阶段。

4.8 业务发现什么时候可以结束

业务发现不是无限期调研。它的目标不是彻底理解一家企业，而是获得足够信息，决定下一步是否值得投入。

当以下问题已有初步答案时，就可以进入场景筛选：

• 谁是用户，谁对结果负责；
• 当前流程怎样运行，主要损失在哪里；
• 需要哪些数据和系统，是否有机会获得；
• 哪些约束不能绕过，失败可能造成什么后果；
• 哪个变化能够被观察和衡量；
• 客户是否愿意为试点提供人员、时间和决策支持。

如果这些问题长期得不到答案，继续做技术原型通常不会让项目更清楚，只会让团队对已经投入的工作产生依赖。

本章小结

业务发现不是询问客户想要什么功能，而是理解工作实际上怎样发生。FDE 要区分愿望、症状、问题和结果，观察正式流程之外的真实操作，从不同角色手中拼出完整事实，并把判断和假设明确标记出来。

发现问题之后，还不能立即开工。下一步要判断：这个问题是否值得用 AI 解决，能否在有限时间内形成闭环，以及什么才是最小但有意义的业务结果。