业务流程图画到什么程度，才能帮助FDE工作

FDE岗位实务指南 · 第06篇

采购负责人发来一张流程图：申请人提交，采购员审核，处理完成。三个方框、两条箭头，看上去十分清楚。

真正跟着采购员操作时，却发现另一番情景：申请在聊天里，物料目录在表格里，用途需要打电话补充，确认以后还要把资料重新录进旧系统。页面上显示“审核通过”，后面的人仍然不知道资料是否已经登记。

如果按最初那张图直接搭Agent流程，很可能只是让第一个方框更快，后面的查找、等待与重录照常发生。

对FDE而言，流程图需要帮助自己和同事回答具体问题：这笔工作现在在哪里，谁拿到了什么资料，依据什么继续，出现异常由谁接手，怎样知道真的完成。

画到什么程度，可以用一个朴素的办法检查：把一笔正常任务和一笔异常任务放进去，别人能不能沿着图继续工作。

为什么审批图齐全仍看不出卡点

本文沿用虚构企业“澄川制造”的采购资料核验情景。人物、申请记录与计时均为教学设定，讨论范围止于资料核验与登记，不包含采购批准和正式下单。

最初的简图可以写成一行：

提交申请 → 审核资料 → 处理结束

作为概览，它没有问题。它告诉我们工作大致经过哪些阶段，却没有说明阶段之间如何衔接。

“提交”是发送一条聊天消息，还是建立一笔带编号的记录？“审核”是确认资料完整，还是批准采购？“结束”是页面显示成功，还是旧系统中已经存在对应资料？不同理解会产生不同实现。

如果三个词没有明确含义，团队可能在同一张图上各自想象。业务以为系统已经完成登记，开发以为返回一个通过标签就算完成，运行人员则不知道失败时该查哪里。

所以，FDE首先要写清这张图的用途。本次用于理解资料从收到、核验到登记的工作，以及其中的等待与异常。它不负责展示全部采购制度，也暂时不画底层部署结构。

起点可以定为“收到一笔可识别的采购资料请求”，终点定为“该笔资料在约定位置登记完成，或进入有明确接手人的待处理状态”。最后一种状态不代表业务成功完成，但它至少说明工作没有无声丢失。

《商业分析知识体系指南》对过程建模区分了不同层次，也讨论了参与者、触发事件、活动、决策、结果及异常路径。本文使用日常语言展开这些要素，不要求读者先背熟完整图形符号。

当别人需要按图配置或操作时，再把影响判断的细节展开。若只是讨论范围，一张概览图可能已经足够。层次取决于图要支持的工作，不能用方框越多判断专业程度。

还要给图标注“当前做法”或“拟议做法”。现在靠电话补单位，将来希望自动检查，两者若混在同一张没有标记的图里，团队会误以为尚待实现的能力已经存在。

跟随一笔记录穿过人和系统

可以先挑一笔具体申请，不急着覆盖所有情况。教学申请A-021写着“滤芯20只，用于维修”，资料核验员认为用途不足，联系申请人后补成“3号机例行维护，更换滤芯”。

观察可以从一张很简单的任务记录开始：申请编号、当前版本、动作时间、操作者、读取资料、产生结果。无法取得的内容标为待核实，不为使表格完整而补写。

例如，看到采购员切换到目录页，只能确认他进行了查找；是否因为助手没有提供依据，还需要追问。把观察到的动作与对原因的解释分开，流程图才不会把猜测固化成后续设计前提。

跟随这笔记录时，每到一个交接点都问三件事：交出了什么，谁收到，凭什么知道下一步可以开始。

申请人发送文字，采购员收到消息。若没有申请编号，就先记录目前如何辨认它。不要在现状图里直接画出一个实际上不存在的统一标识，然后忽略重复和混单问题。

采购员将资料整理进表格，模型可以提取候选字段。这里应当保留原文，并把候选资料与已确认资料分开。否则，后来只看到“20只”，无法知道它来自原申请、模型推测还是人工修改。

核验员接着查看用途和目录依据。发现不足以后，他需要把问题交给申请人。此时交出的应是一条明确的补充请求，而不是笼统的“不通过”。请求要能够指向同一笔申请，说明需要补充什么。

申请人回复以后，核验员重新检查。这个回路应当回到需要重新判断的位置，不能跳过核验直接进入完成，也不一定需要把全部流程从头再走一遍。

资料通过核验后，采购员目前仍需人工录入旧系统。这里必须保持诚实：图上画一条“写入ERP”的箭头，并不会让接口和权限自动出现。现状是什么，就先写什么。

为了方便手机阅读，可以把拟议的工作安排压成一张纵向草图。下面的箭头表示任务衔接，不代表相应接口已经接通。

收到申请：保留原文与编号 ↓ 提取候选资料：保留来源 ↓ 核验资料：检查依据与缺项 ↓ 完整且可确认 人工确认：对应当前版本 ↓ 登记资料：核对实际结果 ↓ 已确认写入 结束：记录完成依据

主线旁再补两条路径：资料不足，交指定人员补充，回来后重新核验；登记结果不清楚，进入结果待查，由约定人员查询，不能直接写成完成。

在团队工作图上，可以将申请人、核验员、业务规则负责人、应用流程、旧系统分别放入泳道。角色与系统在图例中说明，方便讨论交接；公众号正文则保留纵向主线与两条异常说明，避免缩成一张看不清的小字图。

这一遍走完，真正有价值的往往是几条之前没写出的联系：候选资料对应哪份原文，补充消息更新哪一笔记录，确认针对哪个版本，登记结果如何回到处理人面前。

这些联系会影响数据字段、页面、接口和测试。它们也是FDE需要继续核对的实现条件。业务流程图开始有用，正是因为它能产生明确的下一步工作。

补上数据、判断、等待与回退

主线清楚以后，可以在关键交接处增加短说明。无需把所有字段挤进方框，只写决定能否继续的内容，其余资料用编号关联到明细。

例如，从核验员到登记步骤的交接，可以填写成这样：

交出的资料：申请A-021当前版本、已核验字段及确认记录。接收位置：约定的登记页面或接口。继续条件：资料未在确认后被修改，当前操作身份允许登记。完成依据：目标位置存在可对应的登记记录。异常去向：明确失败保留待处理；结果未知先查询，并指定接手人。

这比在箭头旁写“同步数据”更能支持实现。它告诉工程人员需要传什么，也告诉业务人员什么情况下不能宣布完成。

数据尤其要注意版本。核验员看到20只时点了确认，申请人随后改成30只。如果登记步骤只看“已经确认”这个标记，就可能把新的数量与旧的确认混在一起。

流程图中可以将“确认与当前版本一致”写成执行前条件。具体怎样保存版本和校验，后续再由实现方案决定；这张图先让团队意识到，不能把一次确认无限沿用。

交接还要有接收信号。申请人发出了补充消息，是否已经更新到原申请？核验员在聊天中说“收到”，是否等于系统已经记录？若两者没有对应关系，就应在现状图上明确标出人工核对的步骤。

一种有限改进是，让补充入口带上申请编号，并在保存后显示当前版本；核验员从该记录继续处理。它是否适用仍需验证，但已经比“加强沟通”更接近可以实现和检查的动作。

判断节点也需要可说明的条件。“是否合格”太笼统时，应关联到具体规则。是用途不足、物料无法唯一识别，还是单位缺少依据？不同原因可能要找不同的人，补充材料也不同。

例如，“滤芯两箱”与目录单位“只”不一致，若没有包装依据，应该请相应人员核实。不能让申请人随便填一个数，只为使节点走到下一步。

再看等待。发出补充请求以后，记录停在哪里，谁能够看到，什么时候跟进？一个没有承接人的等待框，很容易成为工作遗失的地方。提醒方式和时点应由团队根据任务约定，不能由文章给出通用分钟数。

“进入有人接手的待处理状态”也不能混入完成统计。图中可以将登记完成、等待补充、结果待查、已取消分别写清；它们都可能结束当前操作者的一段工作，却代表不同业务结果。

如果看板把这些记录一律算作已处理，后面的效率数字就会失真。流程与度量需要使用相同含义，才能让团队知道还有多少工作真正没有完成。

等待期间还可能发生新事件：申请人取消了需求，其他同事已经补齐资料，或者原处理人不再负责。流程需要知道哪些事件会结束等待、改变接手人或使旧请求失效。

回退也不能只画一根指向前面的箭头。需要说明退回的对象和保留的信息：原始输入保留吗，补充形成新版本吗，已经生成的提案是否失效，谁知道需要重新处理？

登记超时是另一种不同情况。客户端没有收到响应，后台可能已经写入。此时直接退回“重新提交”，可能产生重复记录。图上应出现结果待查的去向，后续再核实系统支持怎样查询与避免重复。

这并不要求在流程图里完成所有异常工程设计。它要求把异常承接作为工作的一部分，让工程实现、操作说明和测试都能找到对应位置。

遇到业务人员与系统人员看法不一致时，拿同一笔记录共同走图。例如，业务说“我已经提交”，系统人员说“没有收到”。先核对提交发生在哪个入口、哪个时刻、什么记录，避免仅凭一个状态名称争论。

图与实际操作不一致，是有价值的发现。可能是图漏了步骤，也可能是现场长期依靠一条未被认可的绕行办法。应将差异带回相应负责人确认，而不是为了让图整齐，把现场动作删掉。

测量完整任务再决定改哪里

看见重复录入或等待以后，还需要判断它们是否构成主要困难。一张图可以指出测量位置，却不能仅凭箭头多就证明某处最值得自动化。

先定义你要测什么。流转耗时是从约定起点到终点经过的时间；人工投入是人员实际花在工作上的时间。排队、等待回复、机器运行和人员处理可能交错，不能把它们都换算成人工节省。

下面使用一笔独立的模拟记录，演示怎样给流程增加时间。它不是实际客户数据，也不是对前文试点结果的追加统计。

在这个特意设为顺序发生、没有重叠的教学例子里，总流转耗时由20分钟变成16分钟，减少20%。第一段由6分钟变成2分钟，减少约66.7%。两个比例都可以算，但它们回答的是不同问题。

这组记录还没有单独测量人工投入，也没有检查资料质量、返工与维护，因此不能宣布节省了多少人工成本。它能帮助团队看见：整理资料变快了，等待和后续操作仍然存在。

如果再观察几笔任务，发现等待补充主要因为用途提示太笼统，下一步可以先修正提示与样例。如果等待主要因为物料依据不在申请人手里，反复提醒申请人可能只会增加沟通，应调整资料取得和协作方式。

课程用Map、Measure、Repair、Automate帮助组织这类工作：看清过程，取得度量，修复工作中的问题，再判断哪部分适合自动化。这是课程采用的教学顺序，不是行业统一流程标准；实际工作中也可能来回调整。

例如，先把“用途不清”改成说明具体任务与对象，再观察退补是否减少。只有资料和规则逐渐稳定，才更容易检验模型提取、条件检查或系统连接带来了什么变化。

同样，重复录入看起来适合自动化，但要先确认两边字段是否同义、写入身份是否可用、实际结果能否回查。若这些条件暂时不足，可以先改善待登记资料与人工核对，同时把剩余负担写清楚。

测量也需要说明样本条件。不要只挑顺利完成的任务，更不能把未完成任务直接排除后宣布整体提效。困难输入、不同角色和不同等待情况，应当根据业务范围适当覆盖。

若两个人并行工作，同一时间段可能同时包含两份人工投入；若一个人同时处理多笔任务，单笔流转时间又不等于他的持续操作时间。需要什么结论，就设计相应记录，不要拿现有时间戳勉强回答所有问题。

用一条异常检查图能否指导工作

图完成后，可以做一次桌面走查。请没有参与绘图的同事拿着申请A-021，从接收走到登记；作者先观察，只在必要时澄清练习条件。

看他能否说出当前记录是什么、正在处理哪一版、下一步由谁接收，以及完成依据在哪里。如果必须不断依靠作者口头解释，就把缺失信息补回图或附属说明。

然后换一条异常输入：“滤芯两箱”，目录没有包装换算。请他沿图找到补充路径，说明找谁取得依据、等待期间保留什么，以及补充以后回到哪里。

再模拟登记时没有收到响应。观察他是直接再次提交，还是能根据图找到结果待查的安排。这里检验的是流程与责任表达；真正的查询和防重复能力，还需要在相应环境中测试。

也可以让工程同事提出实现问题。如果他问“这个确认针对哪个版本”，而图上没有答案，就补条件；如果他问某个接口是否存在，就将其标为待核实依赖，不能在图上悄悄改成已接通。

桌面走查还可以留下修改记录。例如，第一次接收者不知道去哪查登记结果，于是在登记节点旁补上查询入口与所需标识；第二次能够找到记录，却把旧版本当成当前版本，再补充版本检查。

每次只说“这张图更清楚了”不够，写出哪一处困惑被消除，后面的人就知道修改的目的。若走查发现的是接口暂不支持查询，也应记录为实现条件缺口，不能仅靠改图声称已经解决。

走查以后，一张流程图可能需要配几张小卡：交接资料说明、规则编号、异常去向与运行记录位置。它们共同支持工作即可，不必为了“一张图讲完所有事”把页面挤满。

什么时候可以停下来进入下一步？当约定范围内的正常任务、重要异常和关键交接已经能够被解释，尚未知的条件也有处理人，就可以做有限实现与验证。后续发现新情况，再修订图。

如果还不知道资料确认意味着什么、写入是否真的发生、失败以后谁接手，就应先限制相关实现。否则，流程图看起来已经结束，实际工作却刚刚失去方向。

换到客服辅导情景，也可以使用同样方法：从质检发现到证据核对，再到任务承接和后续记录。重点是让“发现问题”与“有人完成辅导”之间的工作变得可追踪。

今天可以打开一张已有流程图，选一笔最近发生的任务走一遍。圈出一处资料丢失、一处判断不明或一处无人接手，补上实际输入、接收者与核对办法。

一张有用的流程图，会让团队知道接下来查什么、实现什么、测试什么。它的价值体现在这些后续动作里。