Process Mining: Bagaimana hendak mulakan? Bahagian 1

Mari jadikan Proses Purchase-to-Pay sebagai usecase.

Photo by Dion Beetson on Unsplash

Dalam youtube saya yang lepas, saya ada menerangkan asas kepada Process Mining

---

---

Apa kata kali ini kita bawa teori ini ke kepada aplikasi supaya ianya menjadi jelas. Use case yang digunakan kali ini adalah Purchase-to-Pay (P2P).

Berikut adalah checklist untuk menjayakan projek Process Mining (Teknikal):

1. Mengenal pasti Masalah (Problem Statement) dan Potensi Manfaat

2. Mengenal pasti Business SME

3. Mengenal pasti System SME

Mengenal pasti Masalah (Problem Statement) dan Potensi Manfaat

Tidak kenal maka tidak cinta. Jika tidak anda tidak tahu apa masalah yang anda hadapi maka penyelesaikan tidak akan dapat dicari. Dalam usecase kita kali ini adalah berkaitan dengan Purchase-to-Pay. Purchase-to-Pay (P2P) adalah proses yang terlibat semasa anda membuat pesanan barangan sehingga anda membuat pembayaran pesanan.

Masalah (Problem Statement)

Ada beberapa boleh diselesaikan dalam usecase P2P ini, diantaranya adalah:

1. Mengurangkan pembelian seleweng “Maverick Buying” - mengenalpasti mengapa ia berlaku dan di mana ia berlaku

2. Meningkatkan productiviti - mencari langkah-langkah dalam proses yang boleh diautomasikan

3. Mengurangkan kos - sesetengah invoice yang dibayar pada waktu yang ditetapkan akan diberi diskaun

Saya lebih gemar jika anda memilih satu masalah untuk diselesaikan dalam satu masa. Ini memberi anda fokus dan memberi anda memformulasikan hipotesis punca-punca sesuatu isu dan menguji hipotesis tersebut.

Baik untuk kali ini, kita akan memilih issue Pembelian Seleweng (Maverick Buying). Jadi analysis yang dijalankan akan fokus kepada pembandingan antara pembelian yang biasa (mengikut SOP) dan pembelian luar norma.

Mengenal pasti Business SME

Business SME adalah pakar dalam business proses tersebut. SME diperlukan untuk memenuhi lompong kefahaman di antara maklumat digital traces dalam sistem dan aplikasi business.

Mengenal pasti System SME

Dalam rencana yang dikongikan sebelum ini, untuk menjayakan sebuah projek process mining, anda memerlukan digital trace process tersebut yang terdiri daripada:

1. ID Unik - untuk mengenal pasti setiap flow lengkap proses, dalam kes ini Order ID (Wajib)

2. Nama aktiviti (Wajib)

3. Timestamp aktiviti - Bilakah aktivit itu berlaku (Wajib)

4. Sumber - siapakah yang melakukan aktiviti tersebut / atau apakah sistem yang melakukan aktiviti tersebut (Pilihan)

Kerja SME sistem ini menjadi mudah jika event-logs menjadi data “First-Class Citizen”. Apa yang saya maksudkan dengan First-Class Citizen data adalah, anda mempunyai sistem yang merekodkan activiti dengan ciri-ciri yang di atas.

Jika tidak, anda perlu membuat transformasi data daripada pelbagai sistem untuk mendapatkan data diinginkan.

Disebabkan saya tidak mempunyai data P2P yang sebenar, saya ambil data daripada sebuah pertandingan Process Mining.

Data ini diambil daripada sini (segala penerangan data ada di sini). Ia adalah data daripada sebuah syarikat gergasi di yang berada di Belanda mengenai data purchase to pay.

Alat (Tools) yang akan digunakan

Jika anda mempunyai akses kepada Celonis atau mana-mana proses mining tools seperti di sini kerja analysis menjadi lebih mudah. Dalam rencana ini kita gunakan PM4py sebagai senjata utama analysis kita hari ini. PM4py adalah alat sumber terbuka untuk process mining dalam python programming.

Analisa Data

Mari kita install beberapa python libary yang utama

!pip install numpy
!pip install pandas
!pip install pm4p

Ini adalah library utama untuk process mining

!pip install pm4p

Mari kita lihat kandung file event tersebut

import numpy as np # linear algebra
import pandas as pd # baca CSV file

dataframe = pd.read_csv('input/BPI_Challenge_2019.csv', sep=',', encoding='ISO-8859-1')

data_top = dataframe.head() 

data_top

Lihat semua column dalam dataframe

column_names = list(data_top.dataframe)

column_names

['eventID ',
 'case Spend area text',
 'case Company',
 'case Document Type',
 'case Sub spend area text',
 'case Purchasing Document',
 'case Purch. Doc. Category name',
 'case Vendor',
 'case Item Type',
 'case Item Category',
 'case Spend classification text',
 'case Source',
 'case Name',
 'case GR-Based Inv. Verif.',
 'case Item',
 'case concept:name',
 'case Goods Receipt',
 'event User',
 'event org:resource',
 'event concept:name',
 'event Cumulative net worth (EUR)',
 'event time:timestamp']

Sekarang, cari calon-calon data yang sesuai untuk memenuhi keperluaan data Process Mining yang berikut:

1. ID Unik

2. Nama aktiviti

3. Timestamp aktiviti

Berdasarkan maklumat SME Business, column case concept:name sesuai dijadikan ID Unik yang merekodkan perjalanan sebuah pembelian. eventID tidak sesuai digunakan kerana ia adalah unik untuk setiap aktiviti yang direkodkan dalam system.

Manakala Nama aktiviti, gunakan event concept:name kerana column tersebut merekodkan perubahan aktiviti dalam setiap proses P2P. Timestamp Aktiviti ini lebih jelas kerana event time:timestamp column sahaja merekod masa dalam log tersebut.

Apabila anda sudah mendapatkan 3 maklumat utama, mari kita generate eventlog

import pandas as pd
import pm4py

dataframe = pm4py.format_dataframe(dataframe, case_id='case concept:name', activity_key='event concept:name', timestamp_key='event time:timestamp')
event_log = pm4py.convert_to_event_log(dataframe)

Mari lihat bagaimana bentuk log yang telah ditransformasi

event_log[0]

{'attributes': {'concept:name': '2000000000_00001'}, 'events': [{'eventID ': 0, 'case Spend area text': 'CAPEX & SOCS', 'case Company': 'companyID_0000', 'case Document Type': 'EC Purchase order', 'case Sub spend area text': 'Facility Management', 'case Purchasing Document': 2000000000, 'case Purch. Doc. Category name': 'Purchase order', 'case Vendor': 'vendorID_0000', 'case Item Type': 'Standard', 'case Item Category': '3-way match, invoice before GR', 'case Spend classification text': 'NPR', 'case Source': 'sourceSystemID_0000', 'case Name': 'vendor_0000', 'case GR-Based Inv. Verif.': False, 'case Item': 1, 'case concept:name': '2000000000_00001', 'case Goods Receipt': True, 'event User': 'batch_00', 'event org:resource': 'batch_00', 'event concept:name': 'SRM: Created', 'event Cumulative net worth (EUR)': 298.0, 'event time:timestamp': Timestamp('2018-02-01 13:53:00+0000', tz='UTC'), 'concept:name': 'SRM: Created', 'time:timestamp': Timestamp('2018-02-01 13:53:00+0000', tz='UTC'), '@@index': 0, '@@case_index': 0}, '..', {'eventID ': 10, 'case Spend area text': 'CAPEX & SOCS', 'case Company': 'companyID_0000', 'case Document Type': 'EC Purchase order', 'case Sub spend area text': 'Facility Management', 'case Purchasing Document': 2000000000, 'case Purch. Doc. Category name': 'Purchase order', 'case Vendor': 'vendorID_0000', 'case Item Type': 'Standard', 'case Item Category': '3-way match, invoice before GR', 'case Spend classification text': 'NPR', 'case Source': 'sourceSystemID_0000', 'case Name': 'vendor_0000', 'case GR-Based Inv. Verif.': False, 'case Item': 1, 'case concept:name': '2000000000_00001', 'case Goods Receipt': True, 'event User': 'user_001', 'event org:resource': 'user_001', 'event concept:name': 'Record Invoice Receipt', 'event Cumulative net worth (EUR)': 298.0, 'event time:timestamp': Timestamp('2018-06-03 08:53:00+0000', tz='UTC'), 'concept:name': 'Record Invoice Receipt', 'time:timestamp': Timestamp('2018-06-03 08:53:00+0000', tz='UTC'), '@@index': 11, '@@case_index': 0}]}

Setiap proses P2P mesti mempunyai Start Activity dan End Activity. Mari kita lihat adakah semua process mempunyai Start Activity dan End Activity yang sama?

from pm4py.algo.filtering.log.start_activities import start_activities_filter
from pm4py.algo.filtering.log.end_activities import end_activities_filter

start_activities = pm4py.get_start_activities(event_log)

end_activities = pm4py.get_end_activities(event_log)

Start Event dulu

start_activities

{'SRM: Created': 819,
 'Record Goods Receipt': 36263,
 'Clear Invoice': 17905,
 'Record Invoice Receipt': 24402,
 'Record Service Entry Sheet': 1872,
 'Vendor creates invoice': 23835,
 'Vendor creates debit memo': 642,
 'Cancel Invoice Receipt': 350,
 'SRM: In Transfer to Execution Syst.': 2,
 'SRM: Document Completed': 1,
 'SRM: Awaiting Approval': 1,
 'SRM: Change was Transmitted': 1,
 'Create Purchase Order Item': 106773,
 'Change Quantity': 2531,
 'Delete Purchase Order Item': 1174,
 'Block Purchase Order Item': 103,
 'Change Delivery Indicator': 269,
 'Remove Payment Block': 3235,
 'Create Purchase Requisition Item': 27772,
 'Change Approval for Purchase Order': 484,
 'Change Price': 1447,
 'Cancel Goods Receipt': 163,
 'Receive Order Confirmation': 1505,
 'Cancel Subsequent Invoice': 25,
 'Change Storage Location': 36,
...
 'Update Order Confirmation': 29,
 'Reactivate Purchase Order Item': 14,
 'Release Purchase Order': 50,
 'Record Subsequent Invoice': 12,
 'Set Payment Block': 7}

End Activity pula

end_activities

{'Record Invoice Receipt': 54076,
 'SRM: In Transfer to Execution Syst.': 74,
 'SRM: Transfer Failed (E.Sys.)': 21,
 'Record Goods Receipt': 30894,
 'Vendor creates invoice': 16703,
 'SRM: Ordered': 25,
 'Change Delivery Indicator': 602,
 'Clear Invoice': 91520,
 'Create Purchase Order Item': 25936,
 'Record Service Entry Sheet': 1757,
 'SRM: Awaiting Approval': 15,
 'SRM: Change was Transmitted': 23,
 'SRM: Complete': 29,
 'SRM: Document Completed': 18,
 'Delete Purchase Order Item': 6975,
 'Change Final Invoice Indicator': 3,
 'SRM: Transaction Completed': 3,
 'Remove Payment Block': 13005,
 'Cancel Invoice Receipt': 1182,
 'Cancel Goods Receipt': 598,
 'Change Price': 1110,
 'SRM: Deleted': 2,
 'SRM: Created': 1,
 'Change Quantity': 1551,
 'Vendor creates debit memo': 303,
...
 'Release Purchase Order': 99,
 'Create Purchase Requisition Item': 157,
 'Change Storage Location': 44,
 'Change payment term': 1,
 'Release Purchase Requisition': 15}

Banyak pula Start Activity dan End Activity ! Dalam fikiran saya, sama ada proses P2P syarikat adalah rumit atau pun something is wrong (hipotesis awal). Tidak mengapa, kita terima eventlog ini seadanya.

Eventlog Variance

Eventlog Variance ini merujuk kepada berapa jenis flow, end-to-end P2P proses. Jika ianya banyak, ia menunjukkan P2P proses adalam rumit

Jom dapatkan variance eventlog :

variants = pm4py.get_variants(event_log)
print(f"Terdapat: {len(variants)} variants dalam  event logs")

Terdapat: 25041 variants dalam event logs. Banyak betul dan sah P2P syarikat ini adalah rumit. Kita siasat lagi untuk setiap variance ada berapa instance. Kita ambil top 10

from pm4py.statistics.traces.generic.log import case_statistics
#variants_count = pm4py.case_statistics.get_variant_statistics(log)
variants_count = case_statistics.get_variant_statistics(event_log)
variants_count = sorted(variants_count, key=lambda x: x['count'], reverse=True)
variants_count[:10] ## Printing the top 10 variants by case number

[{'variant': ('Create Purchase Order Item',
   'Vendor creates invoice',
   'Record Goods Receipt',
   'Record Invoice Receipt',
   'Clear Invoice'),
  'count': 13607},
 {'variant': ('Create Purchase Order Item', 'Record Goods Receipt'),
  'count': 8618},
 {'variant': ('Create Purchase Order Item',
   'Record Goods Receipt',
   'Vendor creates invoice',
   'Record Invoice Receipt',
   'Clear Invoice'),
  'count': 8384},
 {'variant': ('Create Purchase Order Item', 'Delete Purchase Order Item'),
  'count': 4674},
 {'variant': ('Record Goods Receipt', 'Create Purchase Order Item'),
  'count': 3596},
 {'variant': ('Create Purchase Order Item',
   'Vendor creates invoice',
   'Record Goods Receipt',
   'Clear Invoice',
   'Record Invoice Receipt'),
  'count': 3539},
 {'variant': ('Create Purchase Order Item',
...
   'Record Invoice Receipt',
   'Record Goods Receipt',
   'Remove Payment Block',
   'Clear Invoice'),
  'count': 2958}]

Dalam hasil di atas, variant yang paling utama mempunyai instance sebanyak 13607 iaitu hampir 5% daripada jumlah eventlogs. Berikut adalah variant utama

'Create Purchase Order Item' -->
   'Vendor creates invoice' -->
   'Record Goods Receipt' -->
   'Record Invoice Receipt' -->
   'Clear Invoice'

Setakat dulu hari ini. Nanti kita sambung lagi

Rujukan:

https://www.celonis.com/blog/the-power-of-process-mining-in-purchase-to-pay/

https://pm4py.fit.fraunhofer.de/documentation