如何分析业务流程:流程挖掘洞察实践指南
将流程挖掘仪表板转化为可操作的洞察。学习循序渐进的方法,理解数据,探索模式,并发现实际的改进机会。
您将学到什么
在本指南中,您将学习如何从头开始创建流程挖掘事件日志。我们将介绍事件日志所需的三个关键字段,通过一个真实案例进行讲解,并向您展示如何使用Excel和SQL两种方式构建您的第一个事件日志。
相关阅读: 了解更多关于流程改进的信息,查找适用于您系统的数据模板。同时,也请阅读为什么我们不使用开箱即用的连接器而偏爱简单数据模板。
流程挖掘事件日志本质上是一个数据表,记录了您的业务流程中发生的一切。可以将其视为一个日记,追踪流经您系统的每个案例的每一步。流程挖掘软件会读取这份“日记”,并创建可视化图表,展示您的流程实际如何运作。
每个事件日志的每一行都需要三个核心信息:
| 列名 | 含义 | 示例 |
|---|---|---|
| Case ID(案例ID) | 将相关事件分组的唯一标识符 | 订单 #12345 |
| Timestamp(时间戳) | 事件发生的时间 | 2025-01-15 09:30:00 |
| Activity(活动) | 发生了什么 | “订单已下达” |
就这么简单。仅凭这三列数据,您就可以开始进行流程挖掘。其他所有信息,例如客户姓名、订单金额或员工ID,都是可选的“属性”,用于丰富您的分析。
在我们深入探讨之前,先澄清一个常见的混淆点。
活动是一种行动类型,例如“订单已发货”或“款项已收到”。可以将其视为一个类别或标签。
事件是该活动的一次具体发生。当订单 #12345 在1月15日下午2:30发货时,这就是一个事件。
您的事件日志包含事件,但每个事件都有一个活动名称。实际上,人们经常互换使用这些术语,这也没有问题。请记住:活动是“做什么”,而事件是“何时对谁发生了什么”。
为了让本指南更具实操性,我们以一个虚构系统为例。假设您管理着一家名为Pizza Palace的本地披萨店,该店有一个在线订购系统。顾客通过网站下单,员工制作披萨,然后由配送员送达。
Pizza Palace系统有多个数据库表,用于追踪订单流程的不同部分:
您的目标:创建一个事件日志,显示每笔订单从下单到交付的完整历程。
在构建事件日志时,您会遇到两种类型的事件:
直接事件是系统明确记录的。例如,有人点击了按钮或系统记录了某个操作,数据库中会直接生成一个时间戳。
披萨店示例:
orders表中的时间戳)payments表中的时间戳)delivery_assignments表中的时间戳)推断事件本身可能没有时间戳,但你可以根据其他数据推断出它们发生的时间。
来自披萨宫的示例:
delivery_assignments表中有一个created_at字段,可以显示分配创建的时间关键区别在于:直接事件被明确记录,而推断事件则需要你解读其他数据字段。这两种事件对于流程挖掘都有效且有用。
在提取数据之前,请规划您要捕获哪些事件。对于“披萨宫”,我们将跟踪以下活动:
对于每个事件,需要确定:
这是我们的映射关系:
| 活动 | 源表 | 时间戳字段 | 案例ID字段 |
|---|---|---|---|
| 订单已下达 | orders | created_at | id |
| 收到付款 | payments | payment_time | order_id |
| 订单发送至厨房 | kitchen_queue | queue_entry_time | order_id |
| 订单已备好 | kitchen_queue | completed_time | order_id |
| 已分配给司机 | delivery_assignments | assigned_at | order_id |
| 配送完成 | delivery_assignments | delivered_at | order_id |
虽然案例ID、时间戳和活动是必需的,但属性能够极大地增强您的分析能力。属性是提供额外背景信息的附加字段。
案例属性描述了整个案例(订单),并且在该案例中的所有事件中都相同:
事件属性是每个事件特有的信息:
实用建议: 即使某些属性不适用于特定事件,也完全可以将所有属性都纳入到每一行中。例如,您的“订单已创建”行中,可以有一个空的“司机姓名”列。这样能让事件日志保持简单、扁平的表格格式,而这正是流程挖掘工具所青睐的。
最终的事件日志应是一个表格,其中每一行代表一个事件。以下是我们的“披萨宫”事件日志的示例结构:
| 案例ID | 时间戳 | 活动 | 客户 | 订单金额 | 司机 | 支付方式 |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | 订单已下达 | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:30:15 | 收到付款 | John Smith | 45.99 | Credit Card | |
| 1001 | 2025-01-15 18:31:00 | 订单发送至厨房 | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:45:00 | 订单已备好 | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:46:00 | 已分配给司机 | John Smith | 45.99 | Maria Garcia | |
| 1001 | 2025-01-15 19:05:00 | 配送完成 | John Smith | 45.99 | Maria Garcia | |
| 1002 | 2025-01-15 18:35:00 | 订单已下达 | Jane Doe | 28.50 | ||
| 1002 | 2025-01-15 18:35:20 | 收到付款 | Jane Doe | 28.50 | PayPal | |
| … | … | … | … | … | … | … |
请注意,案例属性(客户、订单金额)在同一案例的每个事件中都会重复出现。这种重复是刻意为之,旨在使数据更易于处理和分析。
如果您可以将数据导出到电子表格中,就可以手动构建事件日志。这种方法非常适用于小型数据集,或在学习阶段使用。
为每种活动类型创建一个工作表:
工作表1:订单已下达
| Case ID | Timestamp | Activity | 客户 | 订单金额 |
|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Order Placed | John Smith | 45.99 |
| 1002 | 2025-01-15 18:35:00 | Order Placed | Jane Doe | 28.50 |
工作表2:款项已收到
| Case ID | Timestamp | Activity | 客户 | 订单金额 | 支付方式 |
|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:15 | Payment Received | John Smith | 45.99 | 信用卡 |
| 1002 | 2025-01-15 18:35:20 | Payment Received | Jane Doe | 28.50 | PayPal |
确保所有工作表具有相同的列且顺序一致。根据需要添加空列:
工作表1:订单已下达(已更新)
| Case ID | Timestamp | Activity | 客户 | 订单金额 | 司机 | 支付方式 |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Order Placed | John Smith | 45.99 |
创建一个新的“事件日志”工作表。将每个活动工作表中的所有行,逐一复制并粘贴到这个合并的工作表中。
选择所有数据并按以下方式排序:
这将使每个案例中的事件按时间顺序排列,从而轻松追踪每个订单的流程。
将合并后的工作表保存为CSV文件。这种格式几乎适用于所有流程挖掘工具。
Excel小贴士:
对于大型数据集或需要定期提取的情况,SQL更高效且可重复。关键技术是使用UNION ALL将多个查询合并为一个结果集。
UNION ALL 将多个 SELECT 语句的结果堆叠在一起。每个 SELECT 语句的结果都会成为最终结果中的一组行。所有 SELECT 语句必须具有相同数量的列且数据类型兼容。
下面是一个创建Pizza Palace事件日志的SQL查询示例:
-- Pizza Palace 事件日志提取
-- 此查询将多种事件类型合并为一个事件日志
-- 每个SELECT块代表一种活动类型
-- 事件1:订单已下达
-- 来源:orders表
-- 捕获客户提交订单的时间
SELECT
o.id AS case_id, -- 订单ID是我们的案例标识符
o.created_at AS timestamp, -- 订单下达时间
'Order Placed' AS activity, -- 活动名称(硬编码)
o.customer_name AS customer, -- 案例属性:下单客户
o.total_amount AS order_value, -- 案例属性:订单金额
NULL AS driver, -- 不适用于此事件
NULL AS payment_method -- 不适用于此事件
FROM orders o
WHERE o.created_at >= '2025-01-01' -- 按您所需的日期范围筛选
UNION ALL
-- 事件2:支付已接收
-- 来源:payments表
-- 捕获成功的支付处理
SELECT
p.order_id AS case_id,
p.payment_time AS timestamp,
'Payment Received' AS activity,
o.customer_name AS customer, -- 连接以获取案例属性
o.total_amount AS order_value,
NULL AS driver,
p.payment_method AS payment_method -- 事件特定属性
FROM payments p
JOIN orders o ON p.order_id = o.id -- 连接以获取订单详情
WHERE p.payment_time >= '2025-01-01'
AND p.status = 'successful' -- 仅包含成功的支付
UNION ALL
-- 事件3:订单已发送至厨房
-- 来源:kitchen_queue表
-- 捕获厨房开始处理订单的时间
SELECT
k.order_id AS case_id,
k.queue_entry_time AS timestamp,
'Order Sent to Kitchen' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
NULL AS driver,
NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'
UNION ALL
-- 事件4:订单已备妥
-- 来源:kitchen_queue表(不同的时间戳字段)
-- 这是根据厨房标记完成时间推断出的事件
SELECT
k.order_id AS case_id,
k.completed_time AS timestamp, -- 与进入时间不同的时间戳
'Order Ready' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
NULL AS driver,
NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
AND k.completed_time IS NOT NULL -- 仅包含已完成的订单
UNION ALL
-- 事件5:已分配配送员
-- 来源:delivery_assignments表
-- 捕获配送员被分配交付订单的时间
SELECT
d.order_id AS case_id,
d.assigned_at AS timestamp,
'Assigned to Driver' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver, -- 事件特定属性
NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'
UNION ALL
-- 事件6:配送已完成
-- 来源:delivery_assignments表(不同的时间戳字段)
-- 捕获订单送达客户的时间
SELECT
d.order_id AS case_id,
d.delivered_at AS timestamp,
'Delivery Completed' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver,
NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
AND d.delivered_at IS NOT NULL -- 仅包含已完成的配送
-- 最终排序:按案例ID,然后按时间
-- 这使得事件日志易于阅读和追踪
ORDER BY case_id, timestamp;
要向您的日志中添加更多事件,请执行以下操作:
例如,要添加一个“配送尝试”事件:
UNION ALL
-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT
d.order_id AS case_id,
d.attempt_time AS timestamp,
'Delivery Attempted' AS activity,
o.customer_name AS customer,
o.total_amount AS order_value,
d.driver_name AS driver,
NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'
首先从三个必需字段和几个关键活动入手。一旦您成功创建了一个基本事件日志并将其加载到流程挖掘工具中,就可以回头添加更多事件和属性。
在深入分析之前,请检查您的事件日志是否存在以下常见问题:
请记录以下信息:
当您日后需要更新或排查事件日志问题时,这份文档将非常有价值。
在所有数据提取过程中保持活动名称的一致性:
如果您的数据来自多个系统或区域,请确保所有时间戳都在同一时区。为保持一致性,UTC通常是最安全的选择。
有时,同一个事件会记录在多个表中。例如,您的订单系统和ERP都可能记录订单发货的时间。
解决方案: 选择一个来源作为“单一事实来源”,并仅使用该来源。记录您的选择。

某些事件可能没有自己的时间戳。例如,“订单已批准”可能只是一个布尔型标志。
解决方案: 查找相关的时间戳。也许有一个“approved_at”字段,或者您可以使用当app%roved标志更改时的“modified_at”时间戳。
如果您有数百万个事件,数据提取时查询可能会很慢甚至崩溃。
解决方案:
一旦您将事件日志创建为CSV文件或数据库导出格式,就可以将其加载到流程挖掘工具中了。大多数工具都遵循类似的操作流程:
像ProcessMind这样的现代流程挖掘工具使这一过程变得简单直观。只需上传您的事件日志,工具就会自动可视化您的流程,揭示瓶颈、变体和改进机会。
创建流程挖掘事件日志并不需要专业的工具或深厚的技术知识。其核心思想是将数据整理成一个包含三个关键列的表格:Case ID(案例ID)、Timestamp(时间戳)和 Activity(活动)。
无论您是使用Excel处理小型数据集,还是使用SQL进行更大、更复杂的数据提取,其基本原则都是相同的:
最难的部分不是技术提取本身,而是要足够了解您的流程,从而知道哪些事件是关键的。从显而易见的事件(例如“订单已下达”、“订单已完成”)开始,随着您了解流程挖掘工具能揭示哪些洞察,逐步添加更多细节。
准备好深入探索了吗?请访问我们的持续流程改进页面,那里有关于采购到付款、订单到现金和应付账款等热门流程的活动与数据要求的详细信息。这些资源包含了SAP、Oracle和Microsoft Dynamics等知名系统的数据模板,助您在创建事件日志的旅程中抢占先机。
立即开始
无需等待完美的事件日志。从您现有的数据开始,从您创建的流程图中学习,并不断迭代。即使是一个包含基本活动的简单事件日志,也能揭示您的流程真实运作方式的惊人洞察。
将流程挖掘仪表板转化为可操作的洞察。学习循序渐进的方法,理解数据,探索模式,并发现实际的改进机会。
即用型连接器承诺为流程挖掘提供简单的数据提取,但往往带来复杂性、延迟和供应商锁定。了解我们使用数据模板的更简单方法。
用data提升流程优化与业务转型效果,助力企业实现高效运营。
2025年Celonis与ProcessMind流程挖掘对比,快速选出适合您业务的流程优化解决方案。
即刻访问,无需信用卡,无需等待。体验MAP、MINE与仿真如何协同,实现更聪明、更快捷决策。
探索全部功能,深挖流程洞见,首日助力运营提效。
立即开启免费试用,释放Process Intelligence全部实力,30天内见证真实提升!