Event log untuk process mining: cara menyusunnya

Process mining dengan log peristiwa dimulai dari satu tabel: aktivitas dengan stempel waktu yang dikelompokkan berdasarkan ID kasus. Panduan ini menunjukkan cara menyusun tabel tersebut dari data sistem menggunakan contoh proses pesanan restoran fiktif. Anda bisa mengikuti dua cara: memasukkan beberapa baris di Excel atau menjalankan satu kueri SQL untuk menggabungkan aktivitas dengan UNION ALL. Bandingkan hasil Anda dengan contoh log yang sudah selesai sambil mengikuti langkah-langkahnya.

Process mining dengan log peristiwa: tiga kolom yang Anda perlukan

Log peristiwa adalah catatan terstruktur tentang kejadian dalam suatu proses. Setiap baris mewakili satu peristiwa, seperti pesanan dibuat atau pembayaran diterima. ID kasus menghubungkan peristiwa yang berkaitan, sedangkan stempel waktu menunjukkan kapan peristiwa terjadi. Dengan keduanya, alat dapat menyusun kembali alur kasus dalam proses.

Aktivitas adalah jenisnya, peristiwa adalah kejadian spesifiknya. Aktivitas adalah jenis tindakan, misalnya “Pesanan Dikirim”. Peristiwa adalah satu kejadian spesifik dari aktivitas itu: pesanan 12345 dikirim pada pukul 14.30 tanggal 15 Januari. Log Anda mencatat peristiwa, dan setiap peristiwa memiliki nama aktivitas. Kedua istilah ini sering dipakai bergantian, tetapi perbedaannya penting saat menyiapkan data. Aktivitas menjelaskan apa yang terjadi, sedangkan peristiwa mencatat bahwa hal itu terjadi pada kasus ini, pada waktu tersebut.

Event log dasar untuk process mining memerlukan tiga kolom:

Sebelum melanjutkan, periksa tiga kolom ini:

Ketiga kolom ini menjadi dasar log peristiwa. Jika salah satunya tidak ada atau tidak konsisten, tampilan proses tidak akan menggambarkan urutan kerja dengan tepat. Kolom lainnya bersifat opsional. Alat process mining bisnis dapat membaca log peristiwa dalam satu tabel berisi kasus dan peristiwa. Tiga kolom yang membuat log peristiwa untuk process mining bisnis dapat digunakan selalu sama. Untuk mengetahui format yang didukung dan langkah persiapannya, lihat dokumentasi data process mining.

Contoh lengkap: sistem pesanan Pizza Palace

Agar langkah-langkahnya lebih jelas, kita akan menggunakan contoh restoran fiktif bernama Pizza Palace. Pelanggan memesan secara online, staf menyiapkan makanan, lalu pengemudi mengantarkannya. Contoh ini tidak menggunakan data pelanggan.

Bayangkan sistemnya menyimpan informasi dalam tabel berikut:

• orders: ID pesanan, pelanggan, dan waktu pemesanan
• order_items: pizza, makanan pendamping, dan minuman dalam setiap pesanan
• kitchen_queue: waktu pesanan masuk dan keluar dari dapur
• delivery_assignments: penugasan pengemudi dan pelacakan pengiriman
• payments: catatan pemrosesan pembayaran

Tujuannya adalah membuat satu event log yang mengikuti setiap pesanan dari saat dibuat hingga dikirim. ID pesanan akan menjadi ID kasus. Setiap stempel waktu dan tindakan yang relevan menjadi satu baris. Unduh contoh event log Pizza Palace sebagai sampel untuk process mining, lalu bandingkan kolomnya dengan ekstrak Anda.

Tentukan aktivitas yang akan disertakan sebelum mengekstrak data. Di Pizza Palace, perjalanan pesanan terdiri dari enam langkah:

1. Order Placed: Pelanggan mengirimkan pesanan.
2. Payment Received: Pembayaran berhasil diproses.
3. Order Sent to Kitchen: Pesanan masuk ke antrean persiapan.
4. Order Ready: Dapur menandai pesanan sebagai selesai.
5. Assigned to Driver: Pengemudi ditugaskan.
6. Delivery Completed: Pesanan telah diantarkan.

Untuk setiap aktivitas, tentukan tabel sumber, kolom stempel waktu, dan kolom ID kasusnya. Pastikan ID kasus menghubungkan peristiwa dengan pesanan yang tepat.

Pisahkan peristiwa langsung dari peristiwa hasil inferensi. Peristiwa langsung memiliki catatan dan stempel waktu yang jelas di sistem sumber. Order Placed menggunakan stempel waktu pada baris orders, Payment Received menggunakan payments, dan Delivery Completed menggunakan delivery_assignments. Peristiwa ini biasanya mudah diekstrak, asalkan stempel waktunya menunjukkan peristiwa yang ingin Anda analisis.

Peristiwa hasil inferensi tidak memiliki catatan tersendiri, jadi waktunya disimpulkan dari kolom lain. Assigned to Driver mungkin hanya tercatat sebagai waktu pembuatan penugasan pengiriman. Order Ready mungkin hanya tercatat saat status antrean dapur berubah menjadi “completed”. Peristiwa hasil inferensi dapat berguna, tetapi dokumentasikan cara Anda menentukannya. Perubahan status atau waktu pembuatan catatan mungkin tidak persis sesuai dengan nama aktivitasnya. Sebelum menganggapnya sebagai stempel waktu peristiwa, tanyakan arti kolom tersebut kepada orang yang memahami sistem sumber.

Pemetaan ini adalah rencana, bukan bukti bahwa setiap kolom sesuai untuk digunakan. Periksa apakah stempel waktu terisi dan apakah setiap tabel dapat digabungkan dengan ID pesanan tanpa menghasilkan baris duplikat.

Atribut kasus dan peristiwa

Atribut menambahkan konteks ke analisis Anda. Atribut adalah kolom selain ID Kasus, Stempel Waktu, dan Aktivitas. Tambahkan atribut hanya jika maknanya jelas dan dapat dikaitkan dengan kasus atau peristiwa yang tepat.

Atribut kasus menjelaskan keseluruhan kasus dan biasanya nilainya sama di semua peristiwa dalam kasus tersebut. Contohnya nama pelanggan, total nilai pesanan, alamat pengiriman, dan jumlah barang yang dipesan. Dalam event log berbentuk tabel datar, nilai ini diulang di setiap baris kasus tersebut. Dengan begitu, nantinya Anda dapat memfilter atau membandingkan peristiwa berdasarkan informasi tingkat kasus.

Atribut peristiwa menjelaskan satu peristiwa, misalnya pengemudi pada peristiwa pengiriman, metode pembayaran pada peristiwa pembayaran, atau stasiun dapur pada peristiwa dapur. Kolom seperti ini tidak berlaku untuk setiap baris. Biarkan kosong jika tidak berlaku, tetapi tetap sertakan kolomnya agar struktur setiap baris sama.

Event log akhir Anda harus berupa satu tabel datar dengan satu peristiwa di setiap baris. Berikut event log Pizza Palace:

Nama pelanggan dan nilai pesanan diulang untuk setiap peristiwa dalam kasus yang sama. Pengulangan ini memang disengaja. Dengan begitu, log tetap berupa tabel sederhana yang dapat dibaca alat process mining.

Metode 1: susun di Excel

Excel cocok untuk ekstrak kecil atau latihan pertama. Ekspor setiap jenis peristiwa, seragamkan kolom, lalu gabungkan barisnya ke dalam satu lembar kerja. Lima langkah berikut memerlukan waktu sekitar satu jam untuk data Pizza Palace.

Langkah 1: ekspor setiap jenis peristiwa ke lembar kerja terpisah. Buat satu lembar kerja untuk setiap jenis aktivitas. Contohnya:

Lembar 1: Order Placed

Lembar 2: Payment Received

Buat lembar kerja tambahan untuk peristiwa dapur dan pengiriman dengan cara yang sama.

Langkah 2: seragamkan kolom. Gunakan nama kolom yang sama dengan urutan yang sama di setiap lembar kerja. Tambahkan kolom kosong jika atribut tidak berlaku. Contohnya, lembar Order Placed dapat memuat semua kolom berikut:

Pastikan nilai menggunakan format yang sesuai satu sama lain. Periksa khususnya agar stempel waktu tersimpan sebagai tanggal dan waktu, bukan sebagai teks yang hanya tampak seperti stempel waktu.

Langkah 3: gabungkan lembar kerja. Buat lembar kerja baru bernama Log Peristiwa, lalu salin baris peristiwa dari setiap lembar aktivitas ke dalamnya. Pertahankan satu baris header dan satu peristiwa di setiap baris.

Langkah 4: urutkan berdasarkan kasus dan stempel waktu. Urutkan data gabungan berdasarkan Case ID dari kecil ke besar, lalu Timestamp dari paling awal. Dengan begitu, urutan setiap kasus lebih mudah ditinjau. Pengurutan tidak memperbaiki stempel waktu yang keliru. Periksa peristiwa dengan waktu yang sama atau tidak wajar sebelum mengandalkan urutannya.

Langkah 5: ekspor ke CSV. Simpan lembar gabungan sebagai CSV log peristiwa process mining yang dapat dibaca oleh alat Anda. Buka file hasil ekspor untuk memastikan header, pemisah, format tanggal, dan nilai kosong sudah sesuai.

Tips Excel:

• Gunakan VLOOKUP atau XLOOKUP untuk menambahkan atribut kasus, seperti nama pelanggan, dari lembar pesanan.
• Gunakan format tanggal dan waktu yang konsisten, misalnya YYYY-MM-DD HH:MM:SS.
• Periksa baris duplikat sebelum mengekspor.
• Simpan salinan ekstrak asli tanpa perubahan agar setiap koreksi dapat ditelusuri.

Metode 2: buat dengan SQL

SQL cocok digunakan jika data Anda tersimpan di database, ekstraknya berukuran besar, atau Anda perlu menjalankan ekstraksi yang sama lagi bulan depan. Umumnya, satu SELECT untuk setiap aktivitas, lalu hasilnya digabung dengan UNION ALL.

Cara kerja UNION ALL. Perintah ini menumpuk baris yang dihasilkan oleh beberapa pernyataan SELECT. Setiap pernyataan harus menghasilkan jumlah kolom yang sama, dalam urutan yang sama, dengan tipe data yang kompatibel dan alias yang konsisten agar nama kolom akhir mudah dipahami.

Kueri. Contoh di bawah menggunakan tabel fiktif Pizza Palace. Sebelum menyesuaikannya, periksa nama tabel dan kolom, arti stempel waktu, serta dialek SQL yang Anda gunakan.

-- 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;

Kueri ini menggunakan ID pesanan sebagai Case ID dan menghasilkan tujuh kolom yang sama untuk setiap aktivitas. Nilai NULL menjaga struktur kolom tetap konsisten saat suatu atribut tidak berlaku. Filter tanggal dan syarat pembayaran berhasil hanya contoh. Pilih filter yang sesuai dengan proses dan periode yang ingin Anda analisis.

Mengembangkan kueri. Untuk menambahkan aktivitas lain:

1. Salin blok SELECT sebagai titik awal.
2. Gunakan tabel sumber yang mencatat peristiwa tersebut.
3. Pilih kolom yang menunjukkan stempel waktunya.
4. Tetapkan nama aktivitas yang konsisten dengan baris lainnya.
5. Sertakan Case ID dan atribut lain yang relevan.
6. Tambahkan filter yang sesuai dengan analisis Anda.

Misalnya, Anda dapat menambahkan percobaan pengiriman seperti ini jika sistem Anda memiliki tabel dan kolom yang diperlukan:

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'

Pemeriksaan sebelum menganalisis log

Lakukan pemeriksaan berikut sebelum menganalisis log. Pemeriksaan ini mencakup pola ketidaksempurnaan log peristiwa yang paling sering menyebabkan hasil process mining menyesatkan: duplikat, stempel waktu yang hilang, Case ID yang tidak konsisten, dan kolom status yang keliru dianggap sebagai aktivitas.

1. Mulai dengan kolom wajib. Buat log sederhana dengan ID kasus, stempel waktu, dan aktivitas sebelum menambahkan peristiwa atau atribut lain.
2. Gunakan ID kasus yang tetap. Gunakan pengenal yang sama untuk setiap peristiwa dalam kasus yang sama. Jangan gunakan nilai yang berubah selama proses berlangsung.
3. Gunakan nama aktivitas secara konsisten. Pilih satu nama, misalnya “Pesanan Dibuat”, dan jangan mencampurnya dengan “Pesanan Dimasukkan” atau “Pesanan Baru”.
4. Periksa stempel waktu. Pastikan stempel waktu menunjukkan waktu terjadinya peristiwa, menggunakan zona waktu yang konsisten, dan dapat diurutkan sebagai tanggal dan waktu.
5. Periksa data duplikat dan nilai yang hilang. Periksa peristiwa yang berulang dan baris yang tidak memiliki ID kasus, stempel waktu, atau aktivitas.
6. Dokumentasikan ekstraksi data. Catat tabel sumber, kolom, filter, tanggal ekstraksi, dan asumsi yang digunakan. Catatan ini memudahkan Anda memperbarui dan menelusuri masalah pada log.
7. Tambahkan atribut dengan cermat. Sertakan kolom yang membantu menjawab pertanyaan, lalu pastikan penggabungan data tidak menggandakan baris peristiwa.

Tujuh masalah data yang umum, mulai dari peristiwa duplikat hingga Case ID yang hilang, dibahas di FAQ pada akhir halaman ini. Sementara itu, panduan ETL untuk process mining membahas proses ekstraksi berulang.

Jika Anda belum memiliki datanya

Anda tidak perlu konektor siap pakai untuk menyiapkan log peristiwa. Periksa dulu data apa yang dapat diekspor dari sistem Anda dan apakah ekspor tersebut mencakup tiga kolom wajib.

1. Tentukan proses dan ID kasus yang ingin Anda telusuri.
2. Periksa apakah sistem dapat mengekspor riwayat peristiwa, catatan audit, atau perubahan status yang memiliki stempel waktu.
3. Gunakan templat data untuk memetakan kolom yang tersedia ke ID kasus, stempel waktu, dan aktivitas.
4. Jika Anda tidak dapat mengekspor tabel peristiwa yang siap digunakan, minta tim data membuat ekstrak basis data atau laporan dengan satu baris untuk setiap peristiwa.

Ekspor dari sistem mungkin berisi beberapa tabel atau menggunakan nama berbeda untuk kolom yang sama. Anda dapat menggabungkan dan mengganti nama data di Excel atau SQL, asalkan makna setiap kolom tetap terjaga dan sumbernya dapat ditelusuri. Sumber data untuk process mining membahas tempat lain yang mungkin menyimpan data sumber yang bisa digunakan. Panduan perbaikan proses telah menyiapkan langkah 1 sampai 3 untuk sistem Anda, lengkap dengan templat data untuk setiap proses.

Jika Anda ingin membandingkan format dengan contoh log peristiwa process mining lainnya, koleksi contoh file log dan templat menyediakan lembar kerja siap pakai. Halaman templat log peristiwa mencantumkan kolom wajib dan opsional. Untuk panduan menggunakan dataset pertama, lihat muat dataset pertama Anda.

Muat log yang Anda buat

Setelah log siap, muat file dan petakan tiga kolom wajibnya. ProcessMind dapat membaca file Excel, CSV, dan ekstrak database secara langsung.

1. Unggah file atau pilih ekstrak basis data Anda.
2. Petakan kolom ID kasus, stempel waktu, dan aktivitas.
3. Periksa atribut tambahan.
4. Buat tampilan proses, lalu pastikan kasus dan urutan peristiwanya masuk akal.

Lihat pemetaan kolom dataset ke peran aktivitas, kasus, dan atribut di ProcessMind

Tampilan proses dapat membantu Anda menemukan aktivitas yang hilang, urutan yang tidak wajar, dan hal-hal yang perlu ditelusuri. Tampilan ini tidak memperbaiki data sumber atau mengubah cara kerja. Jika hasil pertama menunjukkan masalah data, perbarui ekstrak lalu muat ulang. Muat dataset pertama Anda menjelaskan proses unggah dan pemetaan secara terperinci.

Muat log yang baru saja Anda buat