很多企业都画过流程图：订单怎么审批、货怎么发、发票怎么开、款怎么收。但流程图描述的往往是“应该怎么做”，而不是“实际上怎么做”。真实的业务里，订单会被反复修改，审批会被跳过，单据会在某个环节一放就是好几天。流程挖掘的价值，在于用业务系统里已经存在的数据，还原出流程的真实面貌，而不是依赖记忆和印象。
那么，流程挖掘到底是什么，它适合哪些企业，又该如何起步？在这篇文章中，我们将介绍流程挖掘的基本概念及其与传统流程梳理的区别、它依赖的“事件日志”是什么、在订单到收款流程中能发现哪些问题、市场发展到了什么阶段，以及中小企业如何用轻量的方式开始。我们也会讨论一个常被忽视的问题：如何避免让流程挖掘变成员工监控。
什么是流程挖掘？它和传统流程梳理有什么不同？
流程挖掘（Process Mining）是一类从业务系统的事件数据中发现、监控和改进真实流程的方法。它回答的问题不是“流程应该是什么样”，而是“流程实际上是什么样”。
这个领域的学术基础可以追溯到计算机科学家 Wil van der Aalst。他目前是德国亚琛工业大学（RWTH Aachen University）教授，领导流程与数据科学研究组，常被称为“流程挖掘之父”；他从 1990 年代末开始的研究，后来催生了一大批商业和开源的流程挖掘工具（来源）。2011 年，IEEE 流程挖掘工作组发布了《流程挖掘宣言》（Process Mining Manifesto），把流程挖掘定义为从事件日志中提取知识、用来发现、监控和改进“真实流程（而非假设的流程）”的技术、工具和方法（来源）。
宣言把流程挖掘分为三种基本用法，至今仍是理解这项技术最简单的框架：
- 流程发现（Discovery）。 不预设任何模型，直接从数据中画出流程图。例如，把一年的销售订单数据导入后，自动得到订单从创建到收款实际经过的所有路径。
- 合规检查（Conformance）。 把已有的标准流程和实际数据对比，找出偏离的地方。例如，制度规定超过一定金额的采购必须经过总经理审批，数据可以显示有多少单绕过了这一步。
- 流程增强（Enhancement）。 在流程图上叠加时间、频率、成本等信息，看出哪里慢、哪里堵。例如，标出每个环节的平均等待时间，找到最耗时的那一段。
流程挖掘并不是要取代传统的流程梳理。传统方法依靠访谈、工作坊和现场观察，擅长理解“为什么这样做”；流程挖掘依靠系统数据，擅长回答“实际发生了什么、发生了多少次”。下表对比了两者的主要区别：
| 对比项 | 传统流程梳理（访谈、工作坊） | 流程挖掘 |
|---|---|---|
| 信息来源 | 员工的描述和记忆 | 业务系统中的事件记录 |
| 覆盖范围 | 少量典型案例 | 系统中有记录的全部案例 |
| 呈现的流程 | 理想流程或“大家以为的流程” | 实际流程，包括例外和绕行 |
| 量化能力 | 较弱，多为估计 | 能统计频次、时长、偏离比例 |
| 更新速度 | 一次性，重做成本高 | 数据更新后可以重新分析 |
| 擅长回答 | 为什么这样做、有什么约束 | 实际发生了什么、问题在哪里 |
| 主要局限 | 主观、容易遗漏例外 | 只能看到系统里有记录的步骤 |
两者最好结合使用：先用数据找出问题在哪，再用访谈弄清楚问题为什么存在。数据告诉你“哪里不对”，人告诉你“为什么不对”。
流程挖掘是怎么工作的？从事件日志说起
流程挖掘的原材料叫事件日志（Event Log）。只要系统里记录了“哪一单、做了什么、什么时候做的”，就具备了做流程挖掘的基础。
一份最基本的事件日志通常包含三列：
- 案例 ID（Case ID）：标识同一个业务对象，例如销售订单号、采购单号或工单号。
- 活动（Activity）：这个对象经历的步骤，例如“创建订单”“信用审批”“发货”“开票”“收款”。
- 时间戳（Timestamp）：这个步骤发生的时间。
严格来说，《流程挖掘宣言》只要求每条记录能对应到一个案例和一个活动，时间戳、处理人等属于可选的附加信息（来源）。但在实际业务分析中，如果没有时间戳，就无法计算等待时间和找出瓶颈，所以三列都应该准备好。
以“订单到收款”（Order-to-Cash）流程为例，从 ERP 中整理出的事件日志可能是这样的：
| 案例 ID（订单号） | 活动 | 时间戳 |
|---|---|---|
| SO-1001 | 创建订单 | 3 月 2 日 09:15 |
| SO-1001 | 信用审批 | 3 月 2 日 16:40 |
| SO-1001 | 发货 | 3 月 4 日 10:05 |
| SO-1001 | 开票 | 3 月 9 日 14:20 |
| SO-1002 | 创建订单 | 3 月 2 日 10:30 |
| SO-1002 | 修改订单 | 3 月 3 日 11:00 |
| SO-1002 | 发货 | 3 月 3 日 15:30 |
| SO-1002 | 信用审批 | 3 月 5 日 09:10 |
这里的订单号、日期均为示意。单看几行看不出什么，但当几万张订单的记录放在一起，工具会把它们按订单号串起来，再把相同的路径合并，画出一张带频次和时长的流程图。上面这几行已经暴露了两类常见问题：SO-1001 发货后过了 5 天才开票；SO-1002 先发货、后做信用审批，顺序是反的。
在订单到收款流程中，流程挖掘最常发现四类问题：
- 返工。 同一张订单被反复修改价格、数量或交期，或者发票开出后又作废重开。例如，如果大量订单在发货前被修改两次以上，往往说明报价或下单环节的信息不准确。
- 绕行。 实际路径偏离了制度要求。例如，信用审批被跳过或事后补做，大客户订单绕过系统直接安排发货。这类问题不一定违规，但需要确认是否有合理的授权。
- 瓶颈。 某个环节积压了大量案例，处理时间明显长于其他环节。例如，所有超过信用额度的订单都要等财务主管一个人审批，一到月底就排起长队。
- 等待时间。 两个步骤之间什么也没发生，单据只是在“等”。例如，货已经发出，但要等业务员回公司补资料才能开票，开票晚几天，回款也就晚几天。
真正有价值的发现，通常不是“流程很乱”这种笼统的结论，而是“哪一类订单、在哪一步、平均多等了几天”这样具体的事实。 同样的思路也适用于“采购到付款”（Procure-to-Pay）流程：例如，找出先收到发票、后补采购单的情况，或者发票因为三单（采购单、收货单、发票）不一致而被反复退回的环节。
流程挖掘的市场发展到了什么阶段？
流程挖掘已经从学术研究成长为一个独立的软件市场，并且仍在较快增长。但对中小企业而言，比选择哪个平台更重要的，是先弄清楚自己想解决什么问题。
研究机构 Gartner 会定期发布流程挖掘平台的“魔力象限”（Magic Quadrant）评估。据行业媒体 Process Excellence Network 对 Gartner 2025 年 4 月发布的《流程挖掘平台魔力象限》的报道，全球流程挖掘软件市场在 2023 年的收入为 8.716 亿美元，增速为 39.5%；2024 年支出增长超过 30%；Gartner 预计到 2028 年市场规模将超过 20 亿美元，2023 至 2028 年的年均复合增长率约为 18%（来源）。这份报告评估了 16 家厂商。需要说明的是，这些数字衡量的是软件厂商的收入，主要反映大中型企业的采购情况，并不代表中小企业的使用比例。
同一篇报道还总结了 Gartner 对这个市场的几点判断，对理解技术走向有参考价值：
- 基本能力已经标准化。 Gartner 把“事件日志提取、流程模型与分析、对比分析、流程模型增强”列为流程挖掘平台的四项必备功能。
- 采用的驱动力在变化。 除了降本增效和数字化转型，企业引入 AI 和生成式 AI 时，也需要先弄清楚底层流程是怎么运转的。
- 分析对象更贴近真实业务。 一个值得关注的方向是“以对象为中心的流程挖掘”（Object-Centric Process Mining）。传统方法要求每条记录只属于一个案例，而真实业务中，一张订单可能拆成多次发货、合并到一张发票，以对象为中心的方法能同时追踪订单、发货单、发票之间的关系。
这些趋势说明，流程挖掘正在从一次性的“流程诊断”，走向持续的运营监控。对于还没有起步的企业，不必一开始就追求平台化，先用一个流程、一份数据验证价值，是更稳妥的路径。
中小企业如何用轻量的方式开始？分步指南
中小企业做流程挖掘，不一定需要采购昂贵的平台或组建数据团队。大多数 ERP 和业务系统本身就记录了足够的数据，关键是把它们整理成事件日志。 例如，销售订单表里有创建时间，审批记录里有审批时间，发货单、发票和收款单各自都有日期，把这些记录按订单号拼起来，就是一份可用的事件日志。
分析工具也有多种选择：除了商业平台，还有 ProM、PM4Py 等开源工具（来源）；数据量不大时，用表格软件做透视分析，也能回答不少基础问题，例如“发货到开票平均隔几天”。
第 1 步：选一个流程，提一个具体问题。 不要一上来就“把所有流程都挖一遍”。选一个痛点明确、数据集中的流程，例如订单到收款或采购到付款，并把问题写成一句话，例如“为什么我们的平均回款周期比合同账期多出两周？”
第 2 步：找到数据在哪里。 和 IT 人员或系统管理员一起，列出这个流程涉及的单据和表：哪些步骤在系统里有记录、记录在哪张表、时间字段是否可靠。这一步也会暴露数据缺口，例如某个审批是在微信里完成的，系统里没有记录。
第 3 步：导出并整理成事件日志。 先导出 3 到 6 个月的数据，整理成“案例 ID、活动、时间戳”三列，必要时加上处理部门、客户类型、金额等属性。统一活动名称，去掉测试数据和明显的错误记录。数据整理往往是整个项目中最费时的部分，这很正常。
第 4 步：画出实际流程，先看主干再看例外。 用工具生成流程图后，先看最常见的几条路径占了多大比例，再看例外路径。重点关注返工、绕行、积压和长时间等待的环节，并按客户、产品或部门分组比较。
第 5 步：和一线员工一起解读结果。 把发现带回给执行流程的人，问清楚背后的原因。例如，数据显示大量订单在发货后修改价格，可能是因为销售在系统外谈了折扣。没有业务解读的流程图，很容易得出错误的结论。
第 6 步：选一两个改进点，设定基线和目标。 根据影响大小和改动难度，选出最值得做的一两项改进，例如简化小额订单的信用审批、规定发货后 24 小时内开票。记录改进前的指标作为基线，例如平均开票延迟天数。
第 7 步：定期复跑，把一次性诊断变成持续监控。 改进上线后，每月或每季度用新数据重新分析一次，确认指标是否改善、有没有出现新的绕行。当方法跑顺之后，再考虑扩展到第二个流程，或者引入专门的平台工具。
如何避免流程挖掘变成员工监控？
流程挖掘分析的是业务流程，但事件日志里往往带着处理人的信息。如果使用不当，一个流程改进项目很容易被员工理解为“公司在用数据盯着我”，进而失去信任和配合。
员工的这种担忧并非多虑。英国信息专员办公室（ICO）2023 年 10 月发布工作场所监控指南时，引用了一项对 1,012 名英国成年人的调查：约 70% 的受访者认为工作中的监控具有侵入性，57% 表示如果知道会被监控，会对接受这份工作感到不安（来源）。这项调查针对的是一般意义上的工作场所监控，样本来自英国，但它说明了员工对“被数据观察”的普遍敏感。
ICO 的指南要求雇主在监控前用通俗的语言告知员工监控的性质、范围和原因，明确目的并选择侵入性最低的方式，只保留与目的相关的数据；在可能对员工权利造成较高风险时，还应先做数据保护影响评估。《流程挖掘宣言》同样提出，记录事件数据时应处理好隐私和安全问题，相关人员应当知道哪些事件被记录、会被如何使用（来源）。
结合这些原则，企业可以从以下几个方面着手：
- 分析流程，不评价个人。 项目目标写明是改进流程，结果按环节、部门、客户类型汇总，不做个人排名，也不把分析结果直接用于绩效考核。
- 数据最小化与脱敏。 只导出回答问题所需的字段；处理人信息如果不是必需的，就删除或替换为岗位、部门等代码。
- 事先沟通，让员工参与。 在项目启动前说明要分析什么、不分析什么、数据保存多久，并邀请一线员工参与解读结果。
- 遵守所在地法规。 涉及员工个人信息的处理，要符合企业所在地的个人信息保护法规，必要时请法务或合规人员把关。
例如，分析发现某个环节的处理时间特别长，正确的问题是“这个环节的工作量和规则是否合理”，而不是“谁处理得最慢”。把焦点放在流程上，员工才会愿意说出流程背后的真实原因。
关于流程挖掘的常见问题
流程挖掘和 RPA（机器人流程自动化）是什么关系？ 两者解决的是不同的问题。流程挖掘负责看清流程、找出问题，RPA 负责把重复的操作自动化。比较稳妥的顺序是先用流程挖掘确认哪些步骤值得优化或自动化，避免把一个本来就不合理的流程自动化。
我们的 ERP 很旧，数据也不完整，还能做吗？ 通常可以。只要关键单据有编号和日期，就能拼出基础的事件日志。数据缺口本身也是一项发现，例如某些审批没有在系统中留痕，这正是需要改进的地方。
一个流程挖掘项目需要多长时间？ 取决于数据的分散程度和整理难度。如果数据集中在一个系统中、问题定义清晰，第一轮分析往往可以较快完成；数据分散在多个系统中时，整理工作会占用大部分时间。
流程挖掘需要把员工的姓名导出来吗？ 大多数情况下不需要。分析流程问题时，按岗位或部门汇总已经足够。只有在确有必要时才保留处理人信息，并事先告知员工、限制查看权限。
参考资料
- Process Mining Manifesto，IEEE Task Force on Process Mining，2011 年
- Wil van der Aalst 个人主页，RWTH Aachen University 教授个人学术主页，2026 年 11 月访问
- 5 highlights from Gartner's 2025 Magic Quadrant for Process Mining Platforms，Process Excellence Network，2025 年 4 月
- ICO publishes guidance to ensure lawful monitoring in the workplace，英国信息专员办公室（ICO），2023 年 10 月
