如何创建流程挖掘事件日志

您将学到什么

在本指南中,您将学习如何从头开始创建流程挖掘事件日志。我们将介绍事件日志所需的三个关键字段,通过一个真实案例进行讲解,并向您展示如何使用Excel和SQL两种方式构建您的第一个事件日志。

什么是流程挖掘事件日志?

相关: 了解更多持续流程改进 ,并找到适用于你的系统的数据模板 。同时推荐阅读我们为什么不使用开箱即用的连接器,而选择简单的数据模板 。

流程挖掘的事件日志,本质上就是一张记录业务流程中发生事件的表格。可以把它看作系统里每个案例每一步的“日记本”。流程挖掘软件会读取这份“日记”,自动生成可视化流程图,呈现流程实际的运行方式。

每一行至少需要三项关键信息:

列名含义示例
案例ID用于将相关事件归为同一案例的唯一标识订单号12345
时间戳事件发生的时间2025-01-15 09:30:00
活动发生了什么下单

就是这么简单。只凭这三列就能开始做流程挖掘。其他字段,如客户名称、订单金额、员工ID,都属于可选的“属性”,可让你的分析更细致、更有深度。

理解事件与活动的区别

在我们深入探讨之前,先澄清一个常见的混淆点。

活动是一种行动类型,例如“订单已发货”或“款项已收到”。可以将其视为一个类别或标签。

事件是该活动的一次具体发生。当订单 #12345 在1月15日下午2:30发货时,这就是一个事件。

您的事件日志包含事件,但每个事件都有一个活动名称。实际上,人们经常互换使用这些术语,这也没有问题。请记住:活动是“做什么”,而事件是“何时对谁发生了什么”。

我们的案例:Pizza Palace 披萨店订单系统

为了让本指南更具实操性,我们以一个虚构系统为例。假设您管理着一家名为Pizza Palace的本地披萨店,该店有一个在线订购系统。顾客通过网站下单,员工制作披萨,然后由配送员送达。

Pizza Palace系统有多个数据库表,用于追踪订单流程的不同部分:

  • orders - 订单基本信息(订单ID、客户、下单时间)
  • order_items - 订单内容(披萨、配菜、饮品)
  • kitchen_queue - 订单进入和离开厨房的时间
  • delivery_assignments - 配送员分配和配送追踪
  • payments - 支付处理记录

您的目标:创建一个事件日志,显示每笔订单从下单到交付的完整历程。

事件类型:直接事件与推断事件

在构建事件日志时,您会遇到两种类型的事件:

直接事件

直接事件是系统明确记录的。例如,有人点击了按钮或系统记录了某个操作,数据库中会直接生成一个时间戳。

披萨店示例:

  • 订单已下达(orders表中的时间戳)
  • 支付已接收(payments表中的时间戳)
  • 配送已完成(delivery_assignments表中的时间戳)

推断事件

推断事件本身可能没有时间戳,但你可以根据其他数据推断出它们发生的时间。

来自披萨宫的示例:

  • “订单分配给司机”本身可能没有时间戳,但delivery_assignments表中有一个created_at字段,可以显示分配创建的时间
  • “披萨准备就绪”可以根据厨房队列状态变为“已完成”来推断

关键区别在于:直接事件被明确记录,而推断事件则需要你解读其他数据字段。这两种事件对于流程挖掘都有效且有用。

规划事件日志

在提取数据之前,请规划您要捕获哪些事件。对于“披萨宫”,我们将跟踪以下活动:

  1. 订单已下达 - 客户提交订单
  2. 收到付款 - 付款成功处理
  3. 订单发送至厨房 - 订单进入准备队列
  4. 订单已备好 - 厨房标记订单为完成
  5. 已分配给司机 - 为配送任务分配司机
  6. 配送完成 - 订单送达客户

对于每个事件,需要确定:

  • 哪个表包含数据
  • 哪个字段提供时间戳
  • 案例ID是什么(在本例中是订单ID)

这是我们的映射关系:

活动源表时间戳字段案例ID字段
订单已下达orderscreated_atid
收到付款paymentspayment_timeorder_id
订单发送至厨房kitchen_queuequeue_entry_timeorder_id
订单已备好kitchen_queuecompleted_timeorder_id
已分配给司机delivery_assignmentsassigned_atorder_id
配送完成delivery_assignmentsdelivered_atorder_id

添加案例和事件属性

虽然案例ID、时间戳和活动是必需的,但属性能够极大地增强您的分析能力。属性是提供额外背景信息的附加字段。

案例属性

案例属性描述了整个案例(订单),并且在该案例中的所有事件中都相同:

  • 客户名称
  • 订单总价值
  • 收货地址
  • 订购商品数量

事件属性

事件属性是每个事件特有的信息:

  • 司机姓名(仅与配送事件相关)
  • 支付方式(仅与支付事件相关)
  • 后厨工位(仅与后厨事件相关)

实用建议: 即使某些属性不适用于特定事件,也完全可以将所有属性都纳入到每一行中。例如,您的“订单已创建”行中,可以有一个空的“司机姓名”列。这样能让事件日志保持简单、扁平的表格格式,而这正是流程挖掘工具所青睐的。

构建事件日志:简明结构

最终的事件日志应是一个表格,其中每一行代表一个事件。以下是我们的“披萨宫”事件日志的示例结构:

案例ID时间戳活动客户订单金额司机支付方式
10012025-01-15 18:30:00订单已下达John Smith45.99
10012025-01-15 18:30:15收到付款John Smith45.99Credit Card
10012025-01-15 18:31:00订单发送至厨房John Smith45.99
10012025-01-15 18:45:00订单已备好John Smith45.99
10012025-01-15 18:46:00已分配给司机John Smith45.99Maria Garcia
10012025-01-15 19:05:00配送完成John Smith45.99Maria Garcia
10022025-01-15 18:35:00订单已下达Jane Doe28.50
10022025-01-15 18:35:20收到付款Jane Doe28.50PayPal

请注意,案例属性(客户、订单金额)在同一案例的每个事件中都会重复出现。这种重复是刻意为之,旨在使数据更易于处理和分析。

方法一:在Excel中创建事件日志

如果您可以将数据导出到电子表格中,就可以手动构建事件日志。这种方法非常适用于小型数据集,或在学习阶段使用。

步骤1:将每种事件类型导出到单独的工作表

为每种活动类型创建一个工作表:

工作表1:订单已下达

Case IDTimestampActivity客户订单金额
10012025-01-15 18:30:00Order PlacedJohn Smith45.99
10022025-01-15 18:35:00Order PlacedJane Doe28.50

工作表2:款项已收到

Case IDTimestampActivity客户订单金额支付方式
10012025-01-15 18:30:15Payment ReceivedJohn Smith45.99信用卡
10022025-01-15 18:35:20Payment ReceivedJane Doe28.50PayPal

步骤2:标准化列

确保所有工作表具有相同的列且顺序一致。根据需要添加空列:

工作表1:订单已下达(已更新)

Case IDTimestampActivity客户订单金额司机支付方式
10012025-01-15 18:30:00Order PlacedJohn Smith45.99

步骤3:合并所有工作表

创建一个新的“事件日志”工作表。将每个活动工作表中的所有行,逐一复制并粘贴到这个合并的工作表中。

步骤4:先按Case ID,再按Timestamp排序

选择所有数据并按以下方式排序:

  1. Case ID(升序)
  2. Timestamp(升序)

这将使每个案例中的事件按时间顺序排列,从而轻松追踪每个订单的流程。

步骤5:导出为CSV格式

将合并后的工作表保存为CSV文件。这种格式几乎适用于所有流程挖掘工具。

Excel小贴士:

  • 使用VLOOKUP或XLOOKUP从订单工作表中提取案例属性(如客户名称)
  • 使用一致的日期格式(YYYY-MM-DD HH:MM:SS效果最佳)
  • 导出前删除任何重复事件

方法二:使用SQL创建事件日志

对于大型数据集或需要定期提取的情况,SQL更高效且可重复。关键技术是使用UNION ALL将多个查询合并为一个结果集。

理解 UNION ALL

UNION ALL 将多个 SELECT 语句的结果堆叠在一起。每个 SELECT 语句的结果都会成为最终结果中的一组行。所有 SELECT 语句必须具有相同数量的列且数据类型兼容。

完整的SQL示例

下面是一个创建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;

如何扩展此查询

要向您的日志中添加更多事件,请执行以下操作:

  1. 复制其中一个SELECT块作为模板
  2. 将表名更改为您的源表
  3. 将时间戳字段更新为正确的列
  4. 更改活动名称以描述该事件
  5. 根据需要调整属性
  6. 添加适当的WHERE条件来筛选数据

例如,要添加一个“配送尝试”事件:

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'

创建事件日志的最佳实践

1. 先从简单开始,再逐步增加复杂度

首先从三个必需字段和几个关键活动入手。一旦您成功创建了一个基本事件日志并将其加载到流程挖掘工具中,就可以回头添加更多事件和属性。

2. 验证您的数据

在深入分析之前,请检查您的事件日志是否存在以下常见问题:

  • 缺少时间戳 - 没有时间戳的事件会中断流程挖掘
  • 重复事件 - 相同事件被记录两次会使结果失真
  • 事件顺序混乱 - “订单已就绪”事件早于“订单已下达”事件,这表明数据质量存在问题
  • 孤立事件 - 其case ID未在其他活动中出现的事件

3. 记录您的提取过程

记录以下要点:

  • 您使用了哪些表和审计跟踪 (audit trails)
  • 您应用了哪些过滤器 (filters)
  • 提取运行的时间
  • 您所做的任何假设

当您以后需要更新或排查事件日志问题时,这些文档将具有极高的价值。

4. 使用一致的命名

在所有数据提取过程中保持活动名称的一致性:

  • 使用“订单已下达”比有时用“订单已创建”,有时用“新订单”要好
  • 确定一套命名规范并始终遵循

5. 处理时区问题

如果您的数据来自多个系统或区域,请确保所有时间戳都在同一时区。为保持一致性,UTC通常是最安全的选择。

常见挑战与解决方案

流程挖掘事件日志创建中常见挑战的插图

挑战:没有时间戳的事件

某些事件可能没有自己的时间戳。例如,“订单已批准”可能只是一个布尔型标志。

解决方案: 查找相关的时间戳。也许有一个“approved_at”字段,或者您可以使用当app%roved标志更改时的“modified_at”时间戳。

挑战:事件量过大

如果您有数百万个事件,数据提取时查询可能会很慢甚至崩溃。

解决方案:

  • 添加日期筛选器以限制提取周期
  • 分批提取(每次提取一个月的数据),之后再合并文件
  • 考虑使用专用的ETL工具进行大规模数据提取

下一步:将事件日志加载到 Process Mining 工具中

一旦您将事件日志创建为 CSV 文件或数据库导出,就可以将其加载到 Process Mining 工具中了。大多数工具的操作流程都大同小异:

  1. upload 文件或将 Process Mining 工具连接到提取的 data。
  2. 映射您的列 (Case ID, Timestamp, Activity)
  3. 配置任何额外的属性 (Attributes)
  4. 生成您的流程图

ProcessMind  这样的现代 Process Mining 工具让这一过程变得简单直观。只需 upload 您的事件日志 data,工具就会自动将流程可视化,揭示出瓶颈 (bottleneck)、偏差和改进机会,从而帮助降低成本并优化运营流程。

总结

创建 Process Mining 事件日志并不需要专门的工具或深厚的技术知识。其核心在于将 Process Mining data 整理成包含三个基本列的表格:Case ID、Timestamp 和 Activity。

无论您是使用 Excel 处理小型数据集,还是使用 SQL 进行更大规模、更复杂的提取,其原则都是相同的:

  1. 确定要跟踪的 event
  2. 查找每种 event 类型对应的 timestamp
  3. 将所有内容合并到一个表中
  4. 添加属性 (Attributes) 以丰富分析内容

最难的部分往往不是技术提取,而是对业务运营的深入理解,从而确定哪些 event 真正重要。建议从显而易见的 event(如订单下达、订单完成)开始,随着对 Process Mining 工具揭示的洞察的了解,逐步增加更多细节。

准备好深入探索了吗?欢迎访问我们的 持续流程改进页面 。在这里,您可以找到有关 采购到付款 (Purchase to Pay) 、订单到收款 (Order to Cash)  和 应付账款 (Accounts Payable)  等常用流程的 Activity 和 data 要求的详细信息。这些资源还包括了针对 SAP、Oracle 和 Microsoft Dynamics 等主流系统的数据模板,助您在创建事件日志的过程中步入正轨。

立即开始

不要为了追求完美的事件日志而止步不前。从现有数据开始,从生成的流程图中学习,并不断迭代。即使是只包含基础 Activity 的简单事件日志,也能揭示出流程实际运行中令人惊讶的洞察。

相关博客文章

获取Process Mining与workflow优化专家见解,直达您的邮箱
如何分析业务流程:流程挖掘洞察实践指南

如何分析业务流程:流程挖掘洞察实践指南

将流程挖掘仪表板转化为可操作的洞察。学习循序渐进的方法,理解数据,探索模式,并发现实际的改进机会。

为什么我们不采用即用型连接器(以及我们如何替代)

为什么我们不采用即用型连接器(以及我们如何替代)

即用型连接器承诺为流程挖掘提供简单的数据提取,但往往带来复杂性、延迟和供应商锁定。了解我们使用数据模板的更简单方法。

数据驱动流程优化战略指南

数据驱动流程优化战略指南

用data提升流程优化与业务转型效果,助力企业实现高效运营。

Celonis流程挖掘替代方案:ProcessMind更智能的选择

Celonis流程挖掘替代方案:ProcessMind更智能的选择

2025年Celonis与ProcessMind流程挖掘对比,快速选出适合您业务的流程优化解决方案。

挑战自己,30天内实现流程提升!

即刻访问,无需信用卡,无需等待。体验MAP、MINE与仿真如何协同,实现更聪明、更快捷决策。

探索全部功能,深挖流程洞见,首日助力运营提效。

立即开启免费试用,释放Process Intelligence全部实力,30天内见证真实提升!