บันทึกเหตุการณ์สำหรับ process mining: วิธีสร้าง

การทำ process mining ด้วยบันทึกเหตุการณ์เริ่มจากตารางเดียว ซึ่งมีกิจกรรมพร้อมเวลาและจัดกลุ่มตาม ID เคส คู่มือนี้จะแสดงวิธีสร้างตารางจากข้อมูลในระบบ โดยใช้ตัวอย่างกระบวนการสั่งอาหารของร้านสมมติ พร้อมวิธีทำทั้งสองแบบ คือจัดการข้อมูลไม่กี่แถวใน Excel หรือใช้คำสั่ง SQL เดียวเพื่อรวมกิจกรรมเข้าด้วยกันด้วย UNION ALL ระหว่างทำ ลองเปรียบเทียบกับบันทึกเหตุการณ์ตัวอย่างที่ทำเสร็จแล้ว.

บันทึกเหตุการณ์สำหรับ process mining: 3 คอลัมน์ที่ต้องมี

บันทึกเหตุการณ์คือข้อมูลที่มีโครงสร้างและแสดงสิ่งที่เกิดขึ้นในกระบวนการ แต่ละแถวแทนเหตุการณ์หนึ่งรายการ เช่น การส่งคำสั่งซื้อหรือการรับชำระเงิน ID เคสใช้เชื่อมเหตุการณ์ที่เกี่ยวข้อง เวลาใช้ระบุว่าแต่ละเหตุการณ์เกิดขึ้นเมื่อใด เมื่อนำข้อมูลเหล่านี้มารวมกัน เครื่องมือจะสร้างลำดับการเคลื่อนของเคสในกระบวนการได้.

activity คือประเภท ส่วน event คือเหตุการณ์ที่เกิดขึ้นจริง. activity คือการกระทำประเภทหนึ่ง เช่น “จัดส่งคำสั่งซื้อแล้ว” ส่วน event คือเหตุการณ์เฉพาะที่เกิดขึ้นจริง เช่น คำสั่งซื้อ 12345 จัดส่งเมื่อเวลา 14:30 น. วันที่ 15 มกราคม บันทึกของคุณเก็บ event และแต่ละ event จะมีชื่อ activity กำกับ แม้หลายคนจะใช้สองคำนี้แทนกัน แต่ความแตกต่างสำคัญตอนเตรียมข้อมูล เพราะ activity ระบุว่าเกิดอะไรขึ้น ส่วน event ระบุว่าเกิดกับเคสนี้เมื่อใด.

บันทึกเหตุการณ์พื้นฐานสำหรับ process mining ต้องมี 3 คอลัมน์:

ก่อนทำขั้นตอนต่อไป ให้ตรวจสอบทั้ง 3 ฟิลด์นี้:

ฟิลด์ทั้งสามนี้เป็นพื้นฐาน หากฟิลด์ใดหายไปหรือไม่สอดคล้องกัน มุมมองกระบวนการจะแสดงลำดับงานผิดเพี้ยน ส่วนข้อมูลอื่นเป็นตัวเลือกเสริม บันทึกเหตุการณ์ที่เครื่องมือ process mining สำหรับกระบวนการทางธุรกิจอ่านได้จะอยู่ในรูปตารางเดียวที่รวมเคสและเหตุการณ์ไว้ และบันทึกเหตุการณ์สำหรับ process mining จะใช้ได้ก็ต่อเมื่อมีสามคอลัมน์นี้ ดูรูปแบบข้อมูลและขั้นตอนเตรียมข้อมูลที่รองรับได้ในเอกสารข้อมูลสำหรับ process mining.

ตัวอย่างทีละขั้นตอน: ระบบออร์เดอร์ของ Pizza Palace

เพื่อให้เห็นขั้นตอนชัดเจน เราจะใช้ตัวอย่างร้านอาหารสมมติชื่อ Pizza Palace ลูกค้าสั่งอาหารออนไลน์ พนักงานเตรียมอาหาร และคนขับนำไปส่ง ตัวอย่างนี้ไม่มีข้อมูลลูกค้าจริง.

สมมติว่าระบบจัดเก็บข้อมูลไว้ในตารางเหล่านี้:

• orders: ID คำสั่งซื้อ ลูกค้า และเวลาสั่งซื้อ
• order_items: พิซซ่า อาหารทานเล่น และเครื่องดื่มในแต่ละคำสั่งซื้อ
• kitchen_queue: เวลาที่คำสั่งซื้อเข้าคิวและออกจากครัว
• delivery_assignments: การมอบหมายพนักงานส่งอาหารและข้อมูลติดตามการจัดส่ง
• payments: ระเบียนการดำเนินการชำระเงิน

เป้าหมายคือสร้างบันทึกเหตุการณ์เดียวที่ติดตามคำสั่งซื้อแต่ละรายการตั้งแต่รับคำสั่งซื้อจนส่งถึงลูกค้า โดยใช้ ID คำสั่งซื้อเป็น ID เคส ส่วนเวลาและการดำเนินการที่เกี่ยวข้องแต่ละรายการจะกลายเป็นหนึ่งแถว ดาวน์โหลดบันทึกเหตุการณ์ตัวอย่างของ Pizza Palaceเพื่อใช้เป็นตัวอย่างสำหรับ process mining แล้วเปรียบเทียบคอลัมน์กับข้อมูลที่คุณดึงมา.

กำหนดกิจกรรมที่จะรวมก่อนดึงข้อมูล สำหรับ Pizza Palace เส้นทางคำสั่งซื้อมี 6 ขั้นตอน:

1. Order Placed: ลูกค้าส่งคำสั่งซื้อ
2. Payment Received: ระบบดำเนินการชำระเงินสำเร็จ
3. Order Sent to Kitchen: คำสั่งซื้อเข้าสู่คิวเตรียมอาหาร
4. Order Ready: ครัวระบุว่าคำสั่งซื้อเสร็จแล้ว
5. Assigned to Driver: มอบหมายคนขับแล้ว
6. Delivery Completed: จัดส่งคำสั่งซื้อแล้ว.

สำหรับแต่ละกิจกรรม ให้ระบุตารางต้นทาง ฟิลด์เวลา และฟิลด์ ID เคส พร้อมยืนยันว่า ID เคสเชื่อมเหตุการณ์กับคำสั่งซื้อที่ถูกต้อง.

แยกเหตุการณ์ที่บันทึกโดยตรงออกจากเหตุการณ์ที่อนุมานขึ้น. เหตุการณ์ที่บันทึกโดยตรงมีระเบียนและเวลาอย่างชัดเจนในระบบต้นทาง เช่น Order Placed ใช้เวลาจากแถวorders ส่วน Payment Received ใช้จากpayments และ Delivery Completed ใช้จากdelivery_assignments โดยทั่วไปดึงข้อมูลได้ไม่ยาก หากเวลาที่บันทึกตรงกับเหตุการณ์ที่คุณต้องการวิเคราะห์.

เหตุการณ์ที่อนุมานขึ้นไม่มีระเบียนของตัวเอง จึงต้องใช้ฟิลด์อื่นเพื่อระบุเวลา ตัวอย่างเช่น Assigned to Driver อาจมีเพียงเวลาที่สร้างรายการมอบหมายการจัดส่ง ส่วน Order Ready อาจใช้เวลาที่สถานะคิวครัวเปลี่ยนเป็น “completed” เหตุการณ์ที่อนุมานขึ้นอาจมีประโยชน์ แต่ควรบันทึกวิธีอนุมานไว้ เพราะการเปลี่ยนสถานะหรือเวลาสร้างระเบียนอาจไม่ได้หมายถึงสิ่งเดียวกับชื่อกิจกรรม ตรวจสอบความหมายของฟิลด์กับผู้ที่รู้จักระบบต้นทางก่อนนำมาใช้เป็นเวลาเกิดเหตุการณ์.

การจับคู่ข้อมูลนี้เป็นเพียงแผน ไม่ได้ยืนยันว่าทุกฟิลด์เหมาะสม ตรวจสอบว่ามีการบันทึกเวลาไว้จริงหรือไม่ และสามารถ join แต่ละตารางกับ ID คำสั่งซื้อได้โดยไม่ทำให้เกิดแถวซ้ำหรือไม่.

แอตทริบิวต์ของเคสและเหตุการณ์

แอตทริบิวต์ช่วยเพิ่มบริบทให้การวิเคราะห์ เป็นคอลัมน์นอกเหนือจาก ID เคส เวลา และกิจกรรม ควรเพิ่มเมื่อมีความหมายชัดเจนและเชื่อมโยงกับเคสหรือเหตุการณ์ที่ถูกต้องได้เท่านั้น.

แอตทริบิวต์ของเคสอธิบายข้อมูลของเคสทั้งรายการ และมักมีค่าเดิมตลอดทุกเหตุการณ์ของเคสนั้น เช่น ชื่อลูกค้า มูลค่ารวมของคำสั่งซื้อ ที่อยู่จัดส่ง และจำนวนสินค้าที่สั่ง ในบันทึกเหตุการณ์แบบตารางแบน ให้ใส่ค่าเดิมซ้ำในทุกแถวของเคสนั้น เพื่อให้กรองหรือเปรียบเทียบเหตุการณ์ด้วยข้อมูลระดับเคสได้ในภายหลัง.

แอตทริบิวต์ของเหตุการณ์อธิบายเหตุการณ์หนึ่งรายการ เช่น คนขับในเหตุการณ์จัดส่ง วิธีชำระเงินในเหตุการณ์ชำระเงิน หรือสถานีครัวในเหตุการณ์ของครัว คอลัมน์เหล่านี้ใช้กับทุกแถวไม่ได้ ให้เว้นว่างในแถวที่ไม่เกี่ยวข้อง และคงคอลัมน์ไว้เพื่อให้ทุกแถวมีโครงสร้างเหมือนกัน.

บันทึกเหตุการณ์ฉบับสมบูรณ์ควรอยู่ในตารางแบนตารางเดียว โดยหนึ่งแถวแทนหนึ่งเหตุการณ์ ตัวอย่างบันทึกของ Pizza Palace:

ชื่อลูกค้าและมูลค่าคำสั่งซื้อจะปรากฏซ้ำในทุกเหตุการณ์ของเคสเดียวกัน ซึ่งเป็นสิ่งที่ตั้งใจไว้ เพราะช่วยให้บันทึกเหตุการณ์อยู่ในรูปตารางเรียบง่ายที่เครื่องมือ process mining อ่านได้.

วิธีที่ 1: สร้างใน Excel

Excel เหมาะกับข้อมูลที่ดึงมาไม่มากหรือการทดลองทำครั้งแรก ส่งออกข้อมูลของเหตุการณ์แต่ละประเภท จัดคอลัมน์ให้เป็นมาตรฐาน แล้วรวมแถวไว้ในชีตเดียว ขั้นตอนทั้ง 5 ข้อต่อไปนี้ใช้เวลาประมาณหนึ่งชั่วโมงเมื่อทำกับข้อมูลของ Pizza Palace.

ขั้นตอนที่ 1: ส่งออกเหตุการณ์แต่ละประเภทไปยังชีตแยกกัน สร้างชีตสำหรับกิจกรรมแต่ละประเภท ตัวอย่างเช่น:

ชีต 1: สั่งซื้อแล้ว

ชีต 2: ได้รับชำระเงินแล้ว

สร้างชีตเพิ่มเติมสำหรับเหตุการณ์ในครัวและการจัดส่ง โดยใช้วิธีเดียวกัน.

ขั้นตอนที่ 2: ปรับคอลัมน์ให้เป็นมาตรฐาน ใช้ชื่อคอลัมน์และลำดับเดียวกันในทุกชีต แล้วเพิ่มคอลัมน์เปล่าเมื่อแอตทริบิวต์บางรายการไม่เกี่ยวข้อง ตัวอย่างเช่น ชีต สั่งซื้อแล้วสามารถใช้คอลัมน์ทั้งหมดได้ดังนี้:

ตรวจสอบว่าค่าใช้รูปแบบที่เข้ากันได้ โดยเฉพาะเวลา ต้องจัดเก็บเป็นวันที่และเวลา ไม่ใช่ข้อความที่เพียงแค่ดูเหมือนเวลา.

ขั้นตอนที่ 3: รวมชีตเข้าด้วยกัน สร้างชีตใหม่ชื่อ บันทึกเหตุการณ์ แล้วคัดลอกแถวเหตุการณ์จากชีตกิจกรรมแต่ละชีตมารวมกัน โดยคงแถวหัวตารางไว้เพียงแถวเดียวและให้แต่ละแถวแทนหนึ่งเหตุการณ์

ขั้นตอนที่ 4: เรียงตามเคสและเวลา เรียงข้อมูลที่รวมแล้วตาม Case ID จากน้อยไปมาก แล้วตาม Timestamp จากน้อยไปมาก วิธีนี้ช่วยให้ตรวจสอบลำดับของแต่ละเคสได้ง่ายขึ้น การเรียงข้อมูลไม่ได้แก้ไข Timestamp ที่ไม่ถูกต้อง จึงควรตรวจสอบเหตุการณ์ที่มีเวลาเดียวกันหรือเวลาผิดปกติก่อนนำลำดับไปใช้อ้างอิง.

ขั้นตอนที่ 5: ส่งออกเป็น CSV บันทึกชีตที่รวมข้อมูลแล้วเป็นไฟล์ CSV บันทึกเหตุการณ์สำหรับ process mining ที่เครื่องมือของคุณอ่านได้ จากนั้นเปิดไฟล์ที่ส่งออกเพื่อตรวจสอบว่าหัวตาราง ตัวคั่น รูปแบบวันที่ และค่าว่างแสดงผลตามที่คาดไว้.

เคล็ดลับการใช้ Excel:

• ใช้ VLOOKUP หรือ XLOOKUP เพื่อเพิ่มคุณลักษณะของเคส เช่น ชื่อลูกค้า จากชีตคำสั่งซื้อ
• ใช้รูปแบบวันที่และเวลาแบบเดียวกันตลอด เช่น YYYY-MM-DD HH:MM:SS.
• ตรวจสอบแถวที่ซ้ำกันก่อนส่งออก
• เก็บสำเนาข้อมูลต้นฉบับที่ไม่แก้ไขไว้ เพื่อให้ตรวจสอบย้อนกลับได้เมื่อมีการแก้ไข.

วิธีที่ 2: สร้างด้วย SQL

SQL เหมาะเมื่อข้อมูลอยู่ในฐานข้อมูล มีข้อมูลจำนวนมาก หรือต้องดึงข้อมูลชุดเดิมซ้ำในเดือนถัดไป โดยทั่วไปให้สร้าง SELECT สำหรับแต่ละกิจกรรม แล้วนำมาต่อกันด้วย UNION ALL.

UNION ALLทำงานอย่างไร วิธีนี้นำแถวที่ได้จากคำสั่ง SELECT หลายคำสั่งมาต่อกัน แต่ละคำสั่งต้องส่งคืนจำนวนคอลัมน์เท่ากัน เรียงลำดับเหมือนกัน ใช้ชนิดข้อมูลที่เข้ากันได้ และกำหนดชื่อแทนให้สอดคล้องกัน เพื่อให้คอลัมน์สุดท้ายมีชื่อที่ชัดเจน.

คำสั่ง SQL ตัวอย่างด้านล่างใช้ตารางสมมติของ Pizza Palace ก่อนนำไปปรับใช้ ให้ตรวจสอบชื่อตาราง ชื่อฟิลด์ ความหมายของ Timestamp และ SQL dialect ของระบบคุณ.

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS timestamp,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS timestamp,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
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

-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS timestamp,            -- Different timestamp than entry
    '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            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
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,                  -- Event-specific attribute
    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

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
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              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp;

คำสั่งนี้ใช้รหัสคำสั่งซื้อเป็น Case ID และส่งคืนคอลัมน์ 7 คอลัมน์เดิมสำหรับแต่ละกิจกรรม ค่า NULL ช่วยให้โครงสร้างคอลัมน์สอดคล้องกันเมื่อคุณลักษณะบางอย่างไม่เกี่ยวข้อง ตัวกรองวันที่และเงื่อนไขการชำระเงินสำเร็จเป็นเพียงตัวอย่าง ให้เลือกตัวกรองที่ตรงกับกระบวนการและช่วงเวลาที่คุณต้องการวิเคราะห์.

ขยายคำสั่งคิวรี หากต้องการเพิ่มกิจกรรม ให้ทำดังนี้:

1. คัดลอกบล็อก SELECT เพื่อใช้เป็นจุดเริ่มต้น
2. ใช้ตารางต้นทางที่บันทึกเหตุการณ์นั้น
3. เลือกฟิลด์ที่ระบุ Timestamp ของเหตุการณ์
4. ตั้งชื่อกิจกรรมให้สอดคล้องกับแถวอื่น
5. ใส่ Case ID และคุณลักษณะที่เกี่ยวข้อง
6. เพิ่มตัวกรองให้ตรงกับการวิเคราะห์ของคุณ.

ตัวอย่างเช่น คุณอาจเพิ่มความพยายามในการจัดส่งได้ดังนี้ หากระบบของคุณมีตารางและฟิลด์ที่เกี่ยวข้อง:

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'

ตรวจสอบก่อนวิเคราะห์บันทึกเหตุการณ์

ตรวจสอบรายการต่อไปนี้ก่อนวิเคราะห์บันทึก รายการเหล่านี้ครอบคลุมปัญหาที่พบบ่อยในบันทึกเหตุการณ์สำหรับ process mining ซึ่งอาจทำให้ผลวิเคราะห์คลาดเคลื่อน ได้แก่ เหตุการณ์ซ้ำ ไม่มี Timestamp, Case ID ที่ไม่คงที่ และการเข้าใจฟิลด์สถานะผิดว่าเป็นกิจกรรม.

1. เริ่มจากคอลัมน์ที่จำเป็น สร้างบันทึกข้อมูลขนาดเล็กที่มีรหัสเคส เวลา และกิจกรรมก่อน แล้วค่อยเพิ่มเหตุการณ์หรือแอตทริบิวต์อื่น
2. ใช้รหัสเคสที่คงที่ เหตุการณ์ทั้งหมดในเคสเดียวกันควรใช้ตัวระบุเดียวกัน อย่าใช้ค่าที่เปลี่ยนระหว่างกระบวนการ
3. ใช้ชื่อกิจกรรมให้สอดคล้องกัน เลือกชื่อเดียว เช่น “สั่งซื้อแล้ว” อย่าสลับใช้กับ “สร้างใบสั่ง” หรือ “ใบสั่งใหม่”
4. ตรวจสอบเวลา ยืนยันว่าเวลาเป็นเวลาของเหตุการณ์ ใช้เขตเวลาเดียวกัน และเรียงลำดับเป็นวันที่และเวลาได้
5. ตรวจสอบรายการซ้ำและค่าที่ขาดหาย ตรวจสอบเหตุการณ์ที่ซ้ำกัน รวมถึงแถวที่ไม่มีรหัสเคส เวลา หรือกิจกรรม
6. บันทึกรายละเอียดการดึงข้อมูล จดแหล่งที่มาของตาราง ฟิลด์ ตัวกรอง วันที่ดึงข้อมูล และสมมติฐานต่างๆ เพื่อให้อัปเดตและแก้ปัญหาบันทึกข้อมูลได้ง่ายขึ้น
7. เพิ่มแอตทริบิวต์อย่างระมัดระวัง เลือกฟิลด์ที่ช่วยตอบคำถาม และตรวจสอบว่าการ join ไม่ทำให้แถวเหตุการณ์เพิ่มซ้ำ

ปัญหาข้อมูลที่พบบ่อย 7 ข้อ ตั้งแต่เหตุการณ์ซ้ำไปจนถึงไม่มี Case ID มีคำตอบแยกไว้ใน FAQ ท้ายหน้านี้ ส่วน ETL สำหรับ process mining อธิบายวิธีดึงข้อมูลซ้ำเป็นประจำ.

หากคุณยังไม่มีข้อมูล ควรทำอย่างไร

คุณไม่จำเป็นต้องมีตัวเชื่อมต่อที่เตรียมไว้ล่วงหน้าเพื่อจัดทำบันทึกเหตุการณ์ เริ่มจากตรวจสอบว่าระบบส่งออกข้อมูลอะไรได้บ้าง และมีฟิลด์ที่จำเป็นทั้งสามรายการหรือไม่.

1. ระบุกระบวนการและรหัสเคสที่ต้องการติดตาม
2. ตรวจสอบว่าระบบส่งออกประวัติเหตุการณ์ ระเบียนตรวจสอบ หรือการเปลี่ยนสถานะที่มีเวลาได้หรือไม่
3. ใช้เทมเพลตข้อมูลจับคู่ฟิลด์ที่มีอยู่กับรหัสเคส เวลา และกิจกรรม
4. หากส่งออกตารางเหตุการณ์สำเร็จรูปไม่ได้ ให้ขอทีมข้อมูลดึงข้อมูลจากฐานข้อมูลหรือจัดทำรายงานที่มีหนึ่งแถวต่อเหตุการณ์

ไฟล์ส่งออกจากระบบอาจมีหลายตาราง หรือใช้ชื่อฟิลด์ต่างกันทั้งที่หมายถึงสิ่งเดียวกัน คุณรวมและเปลี่ยนชื่อข้อมูลใน Excel หรือ SQL ได้ โดยต้องรักษาความหมายของแต่ละฟิลด์และตรวจสอบย้อนกลับไปยังแหล่งที่มาได้ แหล่งข้อมูลสำหรับ process mining อธิบายแหล่งข้อมูลอื่นที่อาจมีข้อมูลต้นทางที่นำไปใช้ได้ ส่วน คู่มือการปรับปรุงกระบวนการ ได้จัดเตรียมขั้นตอนที่ 1 ถึง 3 สำหรับระบบของคุณ พร้อมเทมเพลตข้อมูลแยกตามกระบวนการไว้แล้ว.

หากต้องการตัวอย่างบันทึกเหตุการณ์สำหรับ process mining เพื่อเปรียบเทียบรูปแบบ คอลเลกชัน ไฟล์ตัวอย่างและเทมเพลต มีสเปรดชีตที่พร้อมใช้ ส่วนหน้า เทมเพลตบันทึกเหตุการณ์ ระบุคอลัมน์ที่จำเป็นและคอลัมน์เสริม หากต้องการดูวิธีใช้ชุดข้อมูลแรก โปรดดู โหลดชุดข้อมูลแรกของคุณ.

โหลดบันทึกเหตุการณ์ที่คุณสร้าง

เมื่อบันทึกพร้อมแล้ว ให้อัปโหลดไฟล์และจับคู่คอลัมน์ที่จำเป็นทั้งสามรายการ ProcessMind อ่านไฟล์ Excel, CSV และข้อมูลที่ดึงจากฐานข้อมูลได้โดยตรง.

1. อัปโหลดไฟล์หรือเลือกข้อมูลที่ดึงจากฐานข้อมูล
2. จับคู่คอลัมน์รหัสเคส เวลา และกิจกรรม
3. ตรวจสอบแอตทริบิวต์เพิ่มเติม
4. สร้างมุมมองกระบวนการ แล้วตรวจสอบว่าเคสและลำดับเหตุการณ์สมเหตุสมผล

ดูการจับคู่คอลัมน์ของชุดข้อมูลกับบทบาทกิจกรรม เคส และคุณลักษณะใน ProcessMind

มุมมองกระบวนการช่วยให้คุณพบกิจกรรมที่ขาดหาย ลำดับที่ไม่คาดคิด และจุดที่ควรตรวจสอบเพิ่มเติม แต่ไม่ได้แก้ไขข้อมูลต้นทางหรือเปลี่ยนวิธีทำงาน หากผลลัพธ์แรกพบปัญหาข้อมูล ให้ปรับข้อมูลที่ดึงมาแล้วโหลดอีกครั้ง โหลดชุดข้อมูลแรกของคุณ อธิบายขั้นตอนอัปโหลดและจับคู่ข้อมูลโดยละเอียด.

โหลดบันทึกเหตุการณ์ที่คุณเพิ่งสร้าง