6.2 隐性流程——客户自己都说不清的那部分

概念

进场访谈挖出来的流程，往往是「显性流程」——写在 SOP 文档里、系统能记录的那部分。

但真正决定项目成败的，是「隐性流程」——没人写下来、没人培训、靠老员工「传帮带」延续的那套做法。

类比：显性流程是地图上能看到的公路，隐性流程是当地人走出来的土路。地图上没有，但人人都走。

为什么隐性流程是 AI 项目最大的坑？

因为 AI 改造的是流程，不是功能。你按显性流程做 RAG，知识库里的文档全是 SOP 手册。但一线真正干活时查的不是手册——是老张工位贴的便利贴、是钉钉群里前辈发的一段语音、是上次出错后老板群发的邮件截图。

你不知道这些隐性知识的存在，知识库的命中率就上不去，Demo 答得再漂亮，真实环境一问就崩。

挖掘隐性流程的四个信号：

访谈中，听到这些话术，立刻提高警惕，往深挖：

三步挖隐性流程：

第一步：跟着一线走一遍。别坐会议室，去工位。让一线操作者当面操作一遍完整流程，你旁边看、旁边问：「这一步为什么要这样？」「如果不这样做会怎样？」「这个数据从哪来？」

第二步：找「最近一次出问题」的案例。问：「上次出问题是什么情况？」——一线回忆真实案例时，会不自觉带出隐性流程。「当时应该是 A，但实际我们做的是 B，因为……」——这个「因为」后面就是金矿。

第三步：对比新老员工。找入职 3 个月的新人和 5 年老员工各一个，问同一个流程怎么处理。两人说法对不上的部分，就是隐性知识断层——这恰恰是 AI 最该补位的地方。

两种极端企业，都要先摸清再动手：

企业类型	特征	FDE 的应对
流程稳定型	制度健全、系统完备，但怕 AI 的随机性，担心破坏既有秩序	先做低风险、高容错的环节；用「人守关口」设计打消顾虑；强调可回滚、可审计
流程混乱型	规则藏在老员工个人经验里，从没沉淀过，换个人就换套做法	这恰恰是价值最大的场景——把隐性经验显性化本身就是交付物。适合「一边跑、一边修路」

提示

中国市场的跳级机会：过去的软件要求先填表、画流程、配规则；AI 的入口是自然语言，而自然语言恰恰是「对话驱动型」组织最熟悉的协作方式。很多客户未必能先把流程画清楚再上系统，反而更适合在 FDE 陪跑下边跑边修。

下面是一个真实案例的隐性流程挖掘过程。

场景：某制造业客户的设备报修流程。

SOP 文档写的流程很标准。但 FDE 跟着一线走了一遍、追问最近出问题的真实案例后，挖出来的实际走法完全是另一回事（这套流程，新员工要靠挨骂才学得会）：

🖼 图：hidden process comparison

为什么这个对 AI 项目至关重要？

如果客户要做「智能派单」AI，你按显性流程做：输入工单 → AI 判断 → 派给维修人员。但真实流程里，派单的决策权在老王脑子里，不在系统里。你做的 AI 要么跟老王打架，要么沦为老王拍板的橡皮图章。

正确做法：先帮老王做辅助决策——AI 给出建议（紧急程度、推荐人选、预计时长），老王确认或调整。跑一段时间，数据沉淀了，再逐步让 AI 自主决策。

注意：客户给你看 SOP 文档时，别当真。SOP 是「应该怎么干」，不是「实际怎么干」。FDE 的活儿就是把「实际怎么干」挖出来，才能判断 AI 在哪一步切入。

隐性流程挖出来后，别急着曝光 。一线愿意告诉你「我们实际是这么干的」，是因为信任你。你转头跟信息化负责人说「一线都在绕过系统」，一线以后不会跟你讲真话。挖隐性流程是为了让 AI 方案落地，不是写整改报告。
隐性流程往往涉及合规风险 。客户一线绕过系统，可能是因为系统流程不合规或不合理，也可能是因为一线在偷懒。你得判断：这个隐性流程值不值得被 AI 接管？有些隐性流程不该被固化进系统，应该被优化掉。
不是所有隐性流程都要 AI 化 。有些隐性流程之所以隐性，是因为它就是低效的。别把低效流程固化成 AI 流程——包装得再好，自动化也只是把问题规模化，低效的本质不会变。