Day 3　业务流程走查与痛点识别

为什么 FDE 必须"走查"业务流程？——从"说"到"看"

先记住这一章最关键的一句话：人说的和人做的，经常不一样。光靠访谈你只能听到"应该怎样"，走查才能看到"实际怎样"。业务流程走查，就是 FDE 亲自下场、亲眼看看这家公司到底是怎么干活的。

1.1 "说一套做一套"的三种情况

Day 2 我们讲了访谈的重要性，但访谈有一个天然的局限：受访者描述的是他"以为"的流程，不是他"实际"的流程。这种差距主要来自三个原因：

• 记忆偏差：一个老员工做了十年的活，他已经忘了自己是怎么一步步操作的了——就像你不会每天记得自己走路先迈哪只脚。你问他流程，他只能给你讲个大概，很多细节他根本意识不到自己在做。
• 理想化滤镜：人会不自觉地把流程说得比实际更规范、更高效。"我们都是按SOP来的"——但实际上SOP上写的是"应该怎么做"，他心里知道实际不是那样，但说出来的时候会不自觉地往SOP上靠。
• 例外盲区：正常流程谁都知道，但那些"不正常"的情况——比如客户突然改地址、比如系统出故障了怎么手工处理——这些例外才是最耗时、最容易出错的地方，但受访者往往觉得"那是特殊情况"，不值得专门讲。

1.2 走查和访谈的关系：两条腿走路

走查不是取代访谈，而是和访谈互补：

1.3 走查的三种方式：旁观、跟岗、自己做

走查不是只有"站在旁边看"这一种方式。根据你和客户的关系、以及你想了解的深度，可以选不同的走查方式：

1.4 走查时该看什么？——走查清单

站在旁边看员工操作，你不能只是"看"，你要有意识地观察这几个维度：

• 动作顺序：他第一步点什么、第二步做什么？有没有反直觉的操作？
• 耗时：每个动作花多久？哪个步骤停了最久？他在等什么？
• 错误和修正：他点错了几次？发现错了怎么改的？改一个错要花多久？
• 切换和等待：他在几个系统之间切换？切换的时候在等什么？
• 表情和情绪：哪里叹气了？哪里皱眉了？哪里笑了？情绪信号往往藏着痛点。
• 土办法：他有没有打开Excel、翻笔记、问旁边的人？这些就是隐性知识和痛点。

1.5 走查前的准备工作

走查不是去了就能看的，你得提前准备。不打无准备之仗：

• 提前要资料：走查之前，先找客户要这些东西——现有流程图（SOP）、组织架构图、系统清单、近一个月的工单/订单/审批数据。这些资料能让你走查的时候心里有底，知道重点看什么。
• 提前约好人：走查需要各个环节的人配合——你不能到了现场才临时找人。提前约好：今天上午看客服部、下午看运营部、明天上午看仓库。每个部门安排1-2个关键人，时间提前定好。
• 准备走查清单：把你要观察的维度列成一个清单——动作顺序、耗时、错误、等待、切换、情绪、土办法。走查的时候对着清单记，不会漏。
• 准备录音/拍照工具：走查的时候尽量录音（征得同意）、拍屏幕（注意保密）——不然你记不过来，回去就忘了细节。

1.6 走查记录：怎么记才不会乱？

走查的时候，信息量大、速度快，你要是不记好笔记，回去就忘了。专业的走查记录方法：

• 按时间线记：从他开始做第一个动作开始，按时间顺序记——"09:00 打开系统A""09:02 导入Excel""09:05 切到系统B复制客户号""09:07 切回系统A粘贴"。时间线式的记录最不容易漏。
• 标问号：遇到你不懂的地方，就打个问号——"？这里为什么要导出两个表？"。走查完之后，专门把这些问号整理出来，集中问业务方。
• 标痛点：遇到明显的痛点——员工叹气了、员工皱眉了、员工花了很长时间在做一件事——就标个"痛点"。这些就是你要重点深挖的地方。
• 录音备份：征得同意后录音，回去可以反复听——很多细节当时记不下来，回去听录音才发现"哦，原来他刚才说了这么多重要的信息"。

流程建模工具：BPMN、流程图、价值链——用哪个？

画业务流程图不是随便画几个框框箭头。行业里有标准的建模语言和方法，你不需要成为BPMN专家，但至少要知道这些工具是什么、什么时候用哪个、画到什么颗粒度合适。FDE的流程图是沟通工具，不是学术论文——能让各方对齐认知就够了。

2.1 BPMN：业务流程建模的国际标准

BPMN（Business Process Model and Notation，业务流程模型与符号）是 OMG（对象管理组织）发布的国际标准，用来用标准化的图形符号来描述业务流程。它的核心价值是：不管你是哪个国家、哪个行业的人，只要学过BPMN，看到同一个图就能理解同一个意思——就像交通标志一样，不用解释大家都认识。^[1]

不过对 FDE 来说，你不需要学会BPMN的全部符号（那东西有上百种符号）。你只需要掌握最常用的几种：

• 开始/结束事件：圆圈，标记流程从哪开始、到哪结束。
• 任务/活动：圆角矩形，代表一个需要做的动作（比如"录入订单""审核发票"）。
• 网关/判断：菱形，代表一个分叉点（比如"是否通过审核？"）。
• 流向箭头：连接各个步骤，代表流程走向。
• 泳道：横向或纵向的分区，把不同角色/部门放在不同泳道里——这个下一节详细讲。

2.2 价值链分析：从"整体价值"到"具体流程"

迈克尔·波特的价值链模型，是从更高的视角看企业怎么创造价值。它把企业活动分成两类：

• 主价值链活动：直接创造价值的——进料物流、生产运营、发货物流、销售与营销、售后服务。这些是直接和客户打交道、直接产生收入的环节。
• 支撑性活动：为主流程提供支持的——企业基础设施、人力资源管理、技术研发、采购管理。这些不直接产生收入，但没有它们主流程跑不起来。

为什么FDE要知道价值链？因为你做流程走查的时候，得先搞清楚：你要走查的那个流程，在整个企业价值链里处于什么位置？是主流程还是支撑流程？它直接影响收入吗？优先级判断的第一步，就是先分主次——主流程上的痛点，通常比支撑流程上的痛点更值钱。

2.3 C4模型：从业务流程到系统架构的桥梁

C4 模型是 Simon Brown 提出的软件架构可视化方法，它用四个层级的抽象来描述系统架构：系统全景图、容器图、组件图、代码图。^[2]对 FDE 来说，C4 最有用的地方是系统上下文图（System Context Diagram）——它能帮你把"业务流程里的各个环节"和"支撑这些环节的系统"对应起来。比如：你在走查"订单处理流程"的时候，可以同时画出这个流程用到了哪些系统（电商平台、ERP、WMS、物流系统），它们之间怎么交互。

2.4 流程挖掘（Process Mining）：当系统有日志时，让数据替你还原流程

前面讲的都是"人工"画法——靠访谈、靠走查、靠老员工回忆来拼出流程图。但如果客户的业务已经跑在信息系统上，系统里天然留有操作日志（谁在什么时间、对哪个单据、做了什么动作），就有一条更硬的路径：流程挖掘。它由 IEEE 流程挖掘任务组（tf-pm.org）等标准化组织推动，核心做法是从系统事件日志里自动还原出"真实发生的流程"，而不是员工嘴上说的"应该怎么跑"。^[2]

它对 FDE 的价值有两点：①校验"口述流程"和"真实流程"的差距——老板说流程很规范，日志一挖却发现大量绕路、跳步、返工；②自动量化瓶颈——哪个环节平均等待最久、哪条"异常路径"走的人最多，日志直接给数字，不用靠人猜。要注意：流程挖掘的前提是系统里有结构化的事件日志；如果客户还靠纸质单、微信群、Excel 干活，就没有日志可挖，只能回到人工走查。FDE 不需要自己实现流程挖掘算法，但要知道"这东西存在、什么时候能用上、结果怎么读"。

2.5 不同颗粒度的流程图：画到什么程度合适？

流程图不是越细越好。画到什么颗粒度，取决于你要解决什么问题：

FDE 做流程走查的时候，通常先画中颗粒——因为你要找痛点、找机会点，不需要细到每个按钮，但也不能太粗到看不清问题。找到痛点之后，再针对那个痛点环节画细颗粒图，作为技术方案的输入。

端到端流程走查：从客户进门到交付完成，一竿子插到底

"端到端"（End-to-End）这个词你会反复听到。它的意思是：不要只看一个部门内部的流程，要从流程的起点（客户产生需求）一直走到终点（交付完成、客户满意），完整走一遍。因为问题最容易藏在部门与部门的"接缝"处。

3.1 为什么"部门视角"会漏掉问题？

如果你只问销售部"你们的流程怎么走"，他会告诉你从获客到签单的全过程，讲得很顺。如果你只问物流部，他会告诉你从接单到送货的全过程，也讲得很顺。但如果你把两个部门的流程接在一起看，你会发现：销售签完单传给物流的时候，中间有两天的等待；销售说的"到货时间"和物流实际的"送达时间"对不上；客户问销售进度，销售还得去问物流。

这些"接缝处"的问题，单看任何一个部门都看不到——因为每个部门都只对自己那段负责。只有端到端走一遍，你才能发现这些"跨部门断点"。

3.2 端到端走查的标准动作

怎么才算"端到端走了一遍"？标准动作是：

1. 选一个最典型的案例：不要选最复杂的、也不要选最简单的，选那个"最普通、最常见"的——比如一张普通的订单、一个标准的售后咨询。用这个案例作为主线，从头走到尾。
2. 从起点开始，跟着走：从客户产生需求那一刻开始，每到一个环节，就问"这一步是谁做的？怎么做的？用什么系统？花多长时间？做完传给谁？"然后走到下一个环节。
3. 记录每个节点：每个节点都记下来——动作、负责人、系统、耗时、产出物。最后把这些节点串起来，就是完整的端到端流程图。
4. 标记断点和等待：哪里交接了、哪里等人、哪里等数据、哪里卡住了——这些就是问题点，用不同颜色标出来。

3.3 端到端走查的常见坑

实际走查的时候，新手很容易踩几个坑：

• 只走主线，不走支线：你跟着一个正常订单走完全流程，觉得挺顺。但那些"不正常"的情况——客户改地址、货品缺货、物流延误——这些支线流程才是最耗时、最容易出错的地方。走查的时候一定要问："如果出现XX情况，流程怎么走？"
• 只走一次，不重复走：你只看一个案例，得出的结论可能是巧合。要多看几个不同类型的案例——大客户订单、小客户订单、加急订单、普通订单——才能看出规律。
• 只看前端，不看后端：你跟着客户体验走了一遍，觉得"下单→付款→发货→收货"很清晰。但后端呢？仓库怎么拣货？财务怎么对账？售后怎么处理？这些后端流程才是成本大头。
• 只问执行者，不问管理者：你问一线员工，他会告诉你"我每天怎么做"。但你要问他的主管："这个流程KPI怎么考核？哪些地方最头疼？"——管理者看到的问题和一线员工看到的不一样，两个视角都要。

四大痛点类型：FDE 的"AI靶点"地图

走完一遍流程，你会看到各种各样的"问题点"。但哪些是AI能解决的？哪些是AI不擅长的？行业里有个经典的四分类法，把业务痛点分成四类，每类对应不同的AI机会。

4.1 四大痛点类型一览

4.2 为什么"经验依赖点"是AI的高价值靶点？

四类痛点里，经验依赖点尤其值得FDE重视。为什么？因为它有三个独特的痛点：

• 培训周期长：新人要3个月甚至半年才能独立做复杂判断，成本高。
• 人员风险高：老员工一离职，经验就带走了，业务直接受影响。
• 难以规模化：有经验的人就那么几个，业务量上去了也顶不住。

而AI（尤其是大模型+知识库）的价值，恰恰就是把这些只存在于人脑子里的隐性经验，变成显性的、结构化的、可复制的知识——让新人在AI辅助下快速达到老员工的水平。这就是为什么Day 1 讲"本体（Ontology）"那么重要：经验依赖点的本质，就是知识没有被结构化、没有被沉淀成系统。

4.3 一个完整案例：四大痛点在同一条流程里

让我们用一个客服工单处理流程的例子，把四大痛点都串起来：

• 耗时点：客服每天早上要花1小时，从三个系统里分别导出工单数据，手动合并成一张表，再开始处理。这1小时就是纯耗时——完全是重复性劳动。
• 出错点：合并Excel的时候，客服经常把两个客户的信息搞混——因为两个客户名字很像，手动复制粘贴的时候看错行。一个月大概出错十几次，每次都要花半小时修正。
• 经验依赖点：遇到"难缠客户"——情绪激动、要求特殊、不在标准SOP里的——普通客服不知道怎么处理，都要转给资深客服张姐。张姐一个人要处理全部门20%的疑难工单。张姐一请假，这些工单就卡住了。
• 人工干预点：客服在工单系统里查到客户信息后，要复制客户号，粘贴到CRM系统里查历史订单，再复制订单号，粘贴到物流系统里查物流——三个系统来回切换，全靠人工搬运信息。

你看，这四个痛点不是分开的——它们在同一条流程里，环环相扣。而每个痛点，都对应着不同的AI解决方案：

4.4 为什么"等待浪费"经常被忽略？

四大痛点里，"耗时点"大家都看得见——员工在忙、在加班，你一看就知道慢。但还有一种浪费特别隐蔽，就是等待浪费——流程没有在动，它在排队、在等人、在等审批、在等数据。这种"什么都没做"的时间，经常被忽略，因为它看起来"没人在干活，好像没成本"。

但实际上，等待的代价非常大：一个流程从下单到发货要5天，其中实际加工时间只有8小时，剩下4天多全在等。你说这个流程慢不慢？当然慢。但如果你只看"实际干活时间"，你会觉得"才8小时，已经很快了"——完全错了。

4.5 四大痛点的优先级排序：哪个最值得先做？

四类痛点不是平等的——它们的AI价值、解决难度、见效速度都不一样。从FDE的实战经验来看，优先级大致是这样的：

痛点量化：把"很烦"变成"每月损失X万"

定性的痛点描述（"很慢、很烦、老出错"）不能用来做决策。FDE 的核心能力之一，就是把模糊的抱怨变成可计算的数字——只有能量化，才能判断值不值得做AI、能省多少钱、ROI怎么样。

5.1 量化的四个维度

5.2 一个完整的量化案例

让我们用一个例子走一遍量化全过程：客服手动把订单从电商后台抄到ERP系统。

• 单次耗时：每个订单平均3分钟。
• 每日频次：每天500个订单。
• 日耗时：500 × 3分钟 = 1500分钟 = 25小时/天。
• 折合人力：按每天8小时算，25 ÷ 8 ≈ 3.1个全职人力。
• 月人力成本：按每人每月8000元算，3.1 × 8000 ≈ 2.5万元/月。
• 错误率：约2%的订单抄错。
• 日错误量：500 × 2% = 10单/天出错。
• 单错损失：每单出错后要核对、改单、道歉，平均损失200元。
• 日错误损失：10 × 200 = 2000元/天。
• 月错误损失：2000 × 22工作日 ≈ 4.4万元/月。
• 合计月损失：2.5万（人力）+ 4.4万（错误）= 约7万元/月。

5.3 量化的一个关键原则：基线思维

量化痛点的本质，是建立基线（Baseline）——也就是"现状是什么样"的数字。为什么基线这么重要？因为你上线AI之后，要证明它有用，就得和上线前对比：时间是不是从3分钟降到3秒了？错误率是不是从2%降到0.1%了？没有基线，你就没法说AI到底有没有用。

5.4 量化的一个常见误区：只算直接成本，不算间接成本

很多人量化痛点的时候，只算最直接的成本——比如"录单花了多少人力"。但实际上，一个痛点的成本远不止这些。完整的成本应该包括：

• 直接人力成本：做这件事花了多少人天，折合多少钱。
• 错误返工成本：做错了要花多少时间修正，造成多少直接损失。
• 延迟成本：流程慢导致客户不满意、错失机会、库存积压的成本。
• 风险成本：因为人工操作，可能造成的合规风险、客户投诉、品牌损失。
• 机会成本：这些人力如果不干这个，能干什么更有价值的事？

举个例子：客服手动录单，直接人力成本是每月2.5万。但如果算上：录错了导致发错货，每月损失4.4万；客户因为发货慢不满意流失，每月潜在损失5万；客服每天花2小时录单，没时间处理真正复杂的客户问题，又损失多少？加起来可能是直接成本的三倍以上。

5.5 量化的一个实用工具：痛点量化打分表

实际工作中，你不可能对每个痛点都做精确的财务计算——那太耗时了。一个更实用的做法是：用打分表快速评估每个痛点的优先级。打分维度包括：

每个痛点按这四个维度打分，然后加权求和，算出一个总分。总分最高的，就是最值得优先做的。这个方法不需要精确的财务数据，只需要你和业务方对打分达成共识——但它能帮你快速排序，比拍脑袋强多了。

泳道图：把"跨部门断点"画在脸上

泳道图（Swimlane Diagram）是业务流程图里最实用的一种画法。它把流程按部门/角色分成不同的"泳道"，哪个部门做什么、哪个部门交接给谁，一目了然。而那些跨部门交接的地方，恰恰就是最容易出问题的断点。

6.1 泳道图为什么好用？

普通的流程图只有流程步骤，你知道"第一步第二步第三步"，但你不知道每一步是谁做的。泳道图的优势就是：责任归属清清楚楚——谁做哪一步、做完传给谁、在哪一步交接的，全都看得见。

更重要的是：跨部门交接的地方，往往就是问题最多的地方。因为每个部门都觉得"我做完我的事就好了"，但交接的时候信息可能丢了、格式可能对不上、对方可能根本没收到——这些问题，单看一个部门发现不了，只有泳道图能把它们"画在脸上"。

6.2 泳道图的三个实战技巧

画泳道图的时候，有三个实战技巧能让你的图更有用：

• 把"等待"标出来：每个节点之间，如果有等待时间，用不同颜色的箭头标出来——比如红色虚线表示等待超过1天。这样一眼就能看出哪里最慢。
• 把"痛点"标出来：在每个痛点节点上贴个标签——"耗时30分钟""错误率2%""老员工才能做"。这样流程图就不只是流程图，还是痛点地图。
• 把"AI机会"标出来：每个痛点旁边，标注可以用什么AI方案解决——"这里可以RPA自动同步""这里可以AI辅助判断"。这样这张图就直接变成了AI机会清单。

现状流程 vs 未来流程：As-Is 和 To-Be

流程走查的产出不只是"画一张现状图"，还要画出"未来应该是什么样"。现状图叫 As-Is（现在怎样），未来图叫 To-Be（将来怎样）。两张图放在一起，差异就是你要做的改造——这也是向客户展示AI价值最直观的方式。

7.1 为什么不能只画现状？

如果你只给客户看现状流程图，他会觉得"嗯，我们现在确实是这么干的，然后呢？"你没告诉他"那又怎样？我为什么要改？"但如果你把 To-Be 也画出来——告诉他"上了AI之后，这个环节从3分钟变成3秒，这个交接从等2天变成自动同步"——他马上就懂了。

7.2 画To-Be图的两个原则

画未来流程图不是随便画——你要遵循两个原则：

• 不要推倒重来：To-Be不是让你重新设计一个全新的流程，而是在As-Is基础上做改造——哪些环节可以砍掉、哪些可以自动化、哪些可以合并。大部分环节应该保留，只改痛点环节。这样客户容易接受，因为他看得出来"这是在我现有基础上优化，不是你给我搞一套全新的东西"。
• 要标注"谁受益"：每改一个环节，就要标注"谁受益？省了多少时间？减少多少错误？"——这样To-Be图就不是一张技术图，而是一张价值图。老板看到每个改动都标着"这里省了3个人/月"，他就知道为什么要做。

瓶颈识别：把力气花在最窄的那截水管上

流程里有很多环节，但不是每个环节都值得优化。经济学里有个"短板理论"：一个木桶能装多少水，取决于最短的那块板。流程也是一样——整条流程的速度，取决于最慢的那个环节。优化非瓶颈环节，不会提升整体效率；只有打通瓶颈，才有显著效果。

8.1 怎么找瓶颈？

瓶颈环节有几个典型特征：

• 耗时最长：整个流程里，这一步花的时间最多。
• 排队最多：这一步前面总是堆着一堆等待处理的单子。
• 经常卡住：这一步经常出问题，导致后面的环节等它。
• 产能受限：这一步的人力/系统能力不够，业务量一上来就堵。

举个例子：一个订单流程，从下单到发货要5天。你拆开看：下单1小时、审核1天、拣货2小时、打包1小时、运输3天。那瓶颈在哪？不是拣货、不是打包——是运输那3天，还有审核那1天。你优化拣货速度从2小时降到1小时，整个流程只快了1小时，几乎看不出变化。但如果你把运输时间从3天降到1天，或者把审核从1天降到2小时，整个流程就明显快了。

8.2 瓶颈的两种类型：产能瓶颈和时间瓶颈

瓶颈不只是"某个环节慢"这么简单。实际上瓶颈分两种：

• 产能瓶颈：这个环节的处理能力有上限——比如仓库只有3个拣货员，每小时最多拣30单，业务量一上来就堵死。这种瓶颈的解决办法：要么加人加设备（增加产能），要么优化流程（提升单位产能）。AI的价值就是后者——比如用智能分拣系统，一个拣货员原来一小时拣10单，现在能拣30单，相当于产能翻3倍。
• 时间瓶颈：这个环节处理能力够，但就是花时间——比如审批要等3天、财务对账要等一周。这种瓶颈不是"人不够"，而是"流程设计不合理"或者"信息没准备好"。AI的价值：自动预审把3天审批压缩到几小时、自动对账把一周的活变成几小时。

为什么要区分这两种瓶颈？因为它们的AI解决方案完全不一样：产能瓶颈要靠"提升单位效率"，时间瓶颈要靠"压缩等待和处理时间"。找错了类型，方案就不对症。

8.3 一个完整的瓶颈分析案例

让我们用一个仓库拣货流程的例子，走一遍瓶颈分析：

一个电商仓库，每天处理1000个订单。拣货流程是：打印拣货单→拣货员按单找货→扫码确认→放到传送带→打包→发货。我们来算一下每个环节的产能：

你看，瓶颈不是"看起来最慢的那个"——而是"产能最接近需求量的那个"。打印单很快、扫码很快，都不是瓶颈。真正的瓶颈是人工拣货（1200单/天 vs 需求1000单），打包也有点紧（800单/天）。

那AI能怎么帮？在拣货环节：智能拣货路径优化——AI帮拣货员规划最优路线，原来一个人一小时拣50单，现在能拣80单。三个人就是240单/小时，1920单/天——产能直接翻倍。打包环节：自动装箱推荐——AI根据订单内容自动推荐用什么箱子，减少打包员的思考时间，从100单/小时提到150单/小时。

痛点与AI能力匹配：别拿锤子找钉子

不是所有痛点都要用AI解决。FDE 的专业判断，就是知道什么痛点配什么技术——该用规则的别用大模型，该用CV的别用文本模型，能用简单方法解决的别上复杂方案。

9.1 常见痛点与AI能力对照表

9.2 一个案例：同一个痛点，不同的技术选型

让我们看一个具体的例子：客服每天要处理大量的客户咨询工单。怎么解决这个痛点？不同的技术选型，效果和成本完全不一样：

你看，同一个"客服工单处理"的痛点，不同的技术选型，成本从几万到几百万不等，效果也完全不一样。FDE的专业能力，就是根据客户的具体情况——数据量、预算、风险承受度——选最合适的方案。不是最贵的最好，也不是最先进的最好，而是最适合的最好。

9.3 怎么判断一个痛点该不该用AI解决？

不是所有痛点都值得用AI解决。判断一个痛点该不该用AI，你可以问自己三个问题：

1. 这个问题是不是重复性的？——如果是一次性的问题，不值得做AI，找个人手工处理就行了。AI适合解决反复发生的、重复性的问题。
2. 这个问题有没有足够的数据？——AI需要数据来学习。如果没有历史数据，或者数据质量很差，AI也学不好。
3. 这个问题的容错率高不高？——如果错了后果很严重（比如医疗诊断、金融授信），那AI只能做辅助，不能全自动。如果错了影响不大（比如客服回复、文案生成），那可以更激进一点。

三个问题都答"是"，那就值得做AI。有一个答"否"，就要谨慎——要么降级为"AI辅助人"，要么先积累数据再说。

走查中的"线下绕行"信号：为什么员工绕开系统？

走查的时候你会发现一个很常见的现象：明明有系统、有流程，但员工偏偏不用，而是用Excel、微信群、纸笔自己搞一套。这种"线下绕行"（Shadow Process）是一个极其重要的信号——它背后一定藏着问题。

10.1 为什么员工要绕开系统？

员工不是天生喜欢麻烦。如果系统好用、靠谱，谁愿意自己搞Excel？他绕开系统，通常是因为：

• 系统不好用：操作太复杂、界面太烂、响应太慢，用系统不如自己做快。
• 系统数据不可信：系统里的数据和实际对不上，不敢用，只能自己再核一遍。
• 系统功能缺失：业务实际需要的东西系统做不到，只能自己想办法补。
• 系统不灵活：SOP规定的流程太死板，实际有很多例外情况系统处理不了，只能线下变通。

10.2 怎么把"线下绕行"变成AI机会？

员工绕开系统搞的那套"土办法"，其实是一个金矿——里面藏着最真实的业务需求。因为员工自己会想办法解决问题，他的Excel表格、他的微信群、他的小本本，都是在填补系统的空白。

所以走查的时候，如果你发现员工在用Excel，不要批评他，反而要拿过来看一看："你这个表是干嘛用的？为什么要用它？"他的Excel设计得越巧妙，说明这个痛点越真实、越重要。因为他花了这么多时间自己搞一套系统，一定是因为这件事对他很重要，而现有系统解决不了。

很多优秀的AI应用，就是从员工的Excel表格里挖出来的：员工自己用Excel做的日报，你帮他自动化；员工自己用Excel做的客户跟进表，你帮他做成CRM功能；员工自己用Excel做的库存预警，你帮他做成智能提醒。他已经把需求"用Excel"表达给你了，你只需要把它系统化、智能化。

10.3 线下绕行的四种类型，对应四种AI机会

员工绕开系统搞的"土办法"，其实可以分成四种类型，每种类型对应不同的AI机会：

你看，员工的"土办法"其实就是在用Excel模拟系统功能。FDE 的工作，就是把这些"Excel模拟的功能"，变成真正的系统功能——而且比Excel更好用、更智能。因为Excel只能做简单的记录，AI还能做预测、做推荐、做自动决策——这就是升级的价值。

向老板汇报：收敛到少数最优机会

走查完流程、找到了一堆痛点、也量化了影响，接下来要向老板汇报。这时候最忌讳的就是把20个机会点全列出来，说"老板您选一个吧"——那是把你的活推给老板。FDE 的专业价值，就是帮他做减法。

11.1 优先级排序：价值 × 可行性

面对一堆机会点，怎么排优先级？用两个维度打分：业务价值（能省多少钱/赚多少钱）和实施可行性（技术难度、数据就绪度、组织配合度）。然后画个四象限矩阵：

• 高价值 × 高可行：速赢区（Quick Win）——优先做，快速出成果建立信心。
• 高价值 × 低可行：战略布局区——价值大但条件不成熟，先补条件、长期规划。
• 低价值 × 高可行：顺手做——成本低，可以作为附属项目一起做。
• 低价值 × 低可行：放弃区——不值得投入。

11.2 汇报的正确姿势：结论先行

给老板汇报，第一句话就说结论："我们走查了XX流程，发现三个最值得优先做的AI机会，第一个是XX，预计每年能省XX万，第二个是……"然后再展开依据，最后说下一步需要什么配合。

千万不要从"我们访谈了X个人、走了X个部门、画了X张图"开始讲——老板不关心你做了多少工作，他关心的是你发现了什么、建议怎么做、能帮我省多少钱。

11.3 汇报的三个层次：现状、问题、建议

向老板汇报流程走查的结果，要按三个层次来讲：

1. 第一层：现状是什么——我们走查了XX流程，现在整个流程从下单到交付要X天，其中实际干活时间X小时，等待时间X天。各部门是怎么配合的，流程节点有哪些。（用流程图说话）
2. 第二层：问题在哪——我们发现了X个主要痛点：第一个是XX，每个月损失X万；第二个是XX，每个月浪费X人力；第三个是XX，客户投诉率X%。（用量化数字说话）
3. 第三层：建议怎么做——基于这些痛点，我们建议优先做这两个AI项目：第一个是XX，预计投入X万，X个月回本，每年省XX万；第二个是XX，……。下一步需要您批准XX资源、协调XX部门配合。（用ROI和资源需求说话）

11.4 一个汇报里绝对不能出现的东西

• 不能说"我们发现了20个问题"——20个问题太多了，老板不知道从哪下手。你要收敛到3个以内，说"我们发现了最关键的三个问题"。
• 不能说"建议您研究一下"——研究什么？怎么研究？这是把你的活推给老板。你要说"我们建议先做XX，原因是……，预计效果是……"。
• 不能说"这个技术很先进"——老板不关心技术先不先进，他关心的是"能帮我解决什么问题、省多少钱"。
• 不能说"大概""可能""也许"——要么拿出数字，要么说"我们初步估算大概是XX量级，下一步可以精确测量"。

11.5 汇报时的一个加分项：用"前后对比图"说话

光靠文字和数字，说服力不够强。最好的汇报方式是：画两张流程图——左边是现状（As-Is），右边是未来（To-Be），中间一个大箭头写"AI改造后"。每张图下面标上关键数字——"现状：5天/单、3个全职人力、错误率2%""未来：1天/单、0.5个全职人力、错误率0.1%"。

这种可视化的对比图，比你讲十分钟都管用。因为老板一眼就能看明白："哦，原来现在这么慢，上了AI之后快这么多，还省这么多人，值。"

11.6 汇报后的跟进：不要说完就走

汇报完了不是结束，只是开始。汇报之后你要做这几件事：

• 发会议纪要：汇报完当天，把结论和待办事项整理成会议纪要发给参会人——"我们今天讨论了XX，结论是优先做A和B，下一步需要张总协调IT部配合，预计下周三出方案"。白纸黑字写下来，避免以后扯皮。
• 跟进决策：汇报完老板说"挺好，我们再研究研究"——那你就要跟进："张总，上次汇报的两个AI项目，您看什么时候能定下来？我们这边好开始做详细方案。"不要等老板主动找你，你要主动推进。
• 收集反馈：汇报完之后，找几个参会人私下聊一聊——"你觉得我们刚才说的那两个方向靠谱吗？有没有什么我们没考虑到的？"公开场合大家可能不好意思提反对意见，私下聊才能听到真话。

今日小结与20题自测回扣

如果今天的内容只能记住一条主线，请记这条：一套方法（端到端走查）+ 四类痛点（耗时/出错/经验依赖/人工干预）+ 一套工具（流程图/泳道图/价值链）+ 一个原则（量化痛点、优先瓶颈、匹配AI能力）。

12.3 今天的内容和后面几天的关系

今天学的是"业务流程走查"——这是FDE工作流的第二步。回顾一下整个FDE的工作流：

1. 第一步（Day 2）：企业调研访谈——先听人说，了解企业的基本情况、业务模式、大家觉得什么是问题。
2. 第二步（Day 3）：业务流程走查——再看人做，亲眼看看实际流程怎么走，找到真正的痛点。
3. 第三步（Day 4）：IT系统盘点——搞清楚支撑这些业务流程的是什么系统，这些系统什么状况。
4. 第四步（Day 5）：数据资产盘点——搞清楚这些系统里的数据怎么样，能不能用。
5. 第五步（Day 6）：AI现状评估——搞清楚企业现在用了什么AI，效果怎么样，还有什么机会。
6. 第六步（Day 7）：五张地图绘制——把前面所有调研的结果，汇总成五张地图，作为后续方案设计的基础。

你看，今天的流程走查是承上启下的——它把Day 2的访谈结果，落到了具体的流程细节上；又为Day 4的IT系统盘点提供了线索：流程里用到哪些系统？这些系统在哪里交接？哪些系统之间需要人工搬运？这些问题，在你画完流程图之后就自然出来了。

12.0b 初学者最容易犯的五个错误

12.1 今日20题考点回扣

12.2 专业防杠清单

Day 3 术语表（大白话版）与今日行动清单

下面这张表，把今天出现的所有行业黑话都翻译成大白话。看完这张表，你就能和企业里的业务人员、IT人员顺畅对话了。

一张表扫清今天的黑话

学完今天，你应该能做到

• 能说出端到端走查的四个标准动作。
• 能识别四大痛点类型，并各举一个例子。
• 能用"时间×频次"算出一个痛点的人力成本。
• 能画出一张带泳道的业务流程图，并标出断点。
• 能区分As-Is和To-Be，并说出两者的关系。
• 能区分产能瓶颈和时间瓶颈。
• 能给老板用"现状→问题→建议"三层结构汇报。

今日实战任务

1. 任务一：画一张流程图——选一个你熟悉的流程（比如你公司的报销流程、或你点外卖到收到的流程），画一张带泳道的流程图，标出至少3个痛点。要求：有开始有结束、有角色泳道、有跨部门交接点。
2. 任务二：量化一个痛点——从你画的流程图里选一个最明显的痛点，用量化方法算出它的月度成本。要求：单次耗时×频次=人力成本，错误率×损失=质量成本，最后加总。
3. 任务三：画To-Be图——基于你量化的痛点，画一张未来流程图（To-Be），标注AI方案和预期效果。要求：保留大部分现有环节，只改痛点环节；标注每个改动省多少钱/时间。
4. 任务四：完成Day 3自测——完成 Day 3 的 20 题自测，把错题对应到本笔记章节再读一遍。

流程走查的行业基准数据参考

流程走查时，怎么判断一个流程"慢不慢、好不好"？可以参考一些行业基准数据：

注意：这些只是参考量级——不同行业、不同规模的企业，基准不一样。不要硬套——要结合客户自己的历史数据、和同行业对比。但有了基准，你就能判断：这个流程是"正常慢"还是"异常慢"。

今天的一句话总结

业务流程走查的本质：别听他说怎么干，要看他实际怎么干；别只看一个部门，要端到端走完整条链；别只说"很慢很烦"，要量化成"每月损失X万"；别列一堆痛点，要收敛到1-2个速赢机会。

记住：FDE不是分析师，不是技术顾问，而是翻译官——把业务的痛翻译成技术能做的事，把技术的能力翻译成老板能懂的价值。业务流程走查，就是这个翻译工作的第一步。

最后再强调一个原则：流程走查的目的，不是"把流程画得多漂亮"——而是"找到真正的痛点，排出优先级，推动第一个改进项目落地"。画完流程图就束之高阁，那不如不画。流程图是工具，不是目的——用它来发现问题、推动改变，才是价值所在。

还有一个心态很重要：不要追求完美。初版流程图画到70分，就可以开始用了——边用边改，边改边完善。追求完美、迟迟不出图——等你画完了，业务都变了。完成比完美重要——这是流程走查的第一原则。

最后送大家一句话："流程是企业的血管——哪里堵了，哪里就该疏通。"业务流程走查，就是给企业做一次"血管造影"——找到堵在哪里、为什么堵、怎么疏通。这就是FDE的价值——不是替企业干活，而是帮企业看清楚自己。

记住：流程走查的终点，不是一张漂亮的流程图——而是一个改进项目的启动。图是手段，改进才是目的。画完图就完了，那是纸上谈兵；画完图、找到痛点、推动改进——那才是FDE。

今天的内容，就到这里。明天我们继续——IT系统盘点与架构理解。

加油，FDE！明天见。Day 3 完。The End.

资料来源与可信度分级

等级图例： 已交叉证实官方 / 一手厂商自述 / 待核实媒体 / 二手汇编

A. 当天指定的 5 份学习资料

B. 本笔记实际引用 / 交叉核实的来源

C. 本笔记的数据口径说明