143 BAB 4 PERANCANGAN DATA MINING 4.1 Arsitektur

BAB 4
PERANCANGAN DATA MINING
4.1
Arsitektur Perancangan Data Mining yang diusulkan
Berdasarkan proses bisnis dan arsitektur sistem informasi yang berjalan (Lihat
subbab 3.3), sumber data yang akan digunakan dalam proses perancangan data mining
ditetapkan diambil dari data warehouse. Hal ini disebabkan karena data yang berada
dalam data warehouse sudah melewati proses pembersihan dan peintegrasian dari
beberapa database operasional, sehingga merupakan data akhir yang dapat memberikan
gambaran keseluruhan suatu proses bisnis perusahaan. Selain itu juga data yang
tersimpan dalam data warehouse bersifat historical. Dikarenakan data di dalam data
warehouse sangat besar dan banyak yang meliputi keseluruhan proses bisnis perusahaan,
maka sumber data yang digunakan untuk proses data mining dibatasi untuk diambil dari
data mart, yaitu data mart penjualan dan data mart penagihan. Data dalam data mart
didesain untuk kebutuhan pemakai akhir pada sebuah unit bisnis strategi atau
departemen. Data mart penjualan dan penagihan mengandung lebih sedikit informasi
dibandingkan dengan data warehouse yang memfokuskan pada transaksi historis
penjualan dan penagihan pelanggan. Untuk lebih jelasnya mengenai skema data mart
penjualan dan penagihan, lihat subbab 3.3, pada Gambar 3.7 dan Gambar 3.8.
Selain data internal perusahaan mengenai penjualan dan penagihan tersebut, juga
diperlukan data eksternal yang bukan dihasilkan dari proses bisnis perusahaan. Data
eksternal ini adalah data penjualan pesaing yang akan digunakan untuk menghasilkan
informasi intelligent bagi perusahaan berupa perbandingan volume penjualan dengan
pesaing baik berdasarkan produk maupun wilayah. Data eksternal ini diperoleh dari hasil
143
144
survey yang dilakukan oleh perusahaan kepada outlet-outlet. Selanjutnya, hasil data
mining ini akan divisualisasikan melalui portal informasi untuk disajikan kepada
eksekutif
perusahaan
melalui
jaringan
LAN
maupun
internet.
Gambar
4.1
menggambarkan arsitektur sistem informasi yang diusulkan untuk perancangan data
mining.
Gambar 4.1 Arsitektur perancangan data mining yang diusulkan
4.2
Pemilihan Tools Data Mining
Untuk menyelesaikan permasalahan data mining, diperlukan suatu tools data
mining yang tepat untuk digunakan oleh PT. Enseval Putera M egatrading. Saat ini
terdapat tiga buah software yang menjadi pemimpin dalam bidang Data mining, yakni
SAS Enterprise Miner 5.3, SPSS Clementine dan Oracle Data Miner. Tabel 4.1
menunjukkan perbandingan ketiga software tersebut yang menjadi pertimbangan dalam
menentukan tools data mining yang akan digunakan.
145
Tabel 4.1 Perbandingan Tools Data mining
Vendor
Nama
aplikasi
terbaru
Algoritma
inside
IT Platform
Documentati
on
Strength
Oracle
Oracle Data M iner
11g
S AS
Enterprise M iner 5.3
Clasification
Clustering and self
Decision Tree
organizing maps
Naive Bayes
M arket basket
Support Vector
analysis
M achine
Sequence and Web
Regression
path analysis
Active Support
Variable clustering
Vector M achine
and selection
Attribut Importance
Linear and logistic
M inimum
regression
Description Length
Decision Tree
Anomaly Detection
Gradient boosting
One-Class Support
Neural networks
Vector M achine
Partial least square
Clustering
regression
Enhanced K-M eans
Support Vector
Orthogonal
M achine(experimenta
Partitioning
l)
Clustering
Two-stage modelling
Association
M emory-based
Apriori
reasoning
Feature Extraction
M odel ensembles,
Non-Negative M atrix
including bagging
nFactorization
and boosting
Java API
PL/SQL API
Promotional Content
Development Content
Conceptual Content
In-database Data
mining
Dapat diintegrasikan
dengan Clementine
Java dan PL/SQL
sudah umum
digunakan
Dokumentasi untuk
S PSS
Clementine 12
Clasification
Binary classifier and
numeric predictor
Support Vector
M achine
Bayesian Networks
Cox Regression
Segmentation
Kohenen Network
TwoStep Clustering
Anomaly Detection
Association
Apriori
CARM A
Sequence
SAS Code
Unknown
Promotional Content
Promotional Content
Conceptual Content
M emiliki algortima
yang jenisnya lebih
banyak
Popular
Statistik yang lebih
advance
Dapat diintegrasikan
dengan Oracle Data
M iner
146
Weakness
developer yang
sangat lengkap
Saat ini
popularitasnya masih
kalah dibanding
SPSS dan SAS
dikarenakan sudah
menjadi kategori
yang dibedakan
dengan Customer
Data mining karena
Oracle Data Miner
embeded dengan
Oracle Database
External Database
External Database
Dokumentasi untuk
developer kurang
tersedia
Berdasarkan Tabel 4.1 diatas, akhirnya disimpulkan Oracle Data mining
merupakan pilihan yang terbaik untuk melakukan data mining di PT. Enseval Putera
M egatrading. Hal ini disebabkan beberapa alasan sebagai berikut :
•
Oracle Data Miner merupakan tools data mining yang basisnya in-database,
artinya user tidak perlu melakukan database movement dari platform database
server ke aplikasi data mining. Hal ini akan mengurangi waktu proses yang
memakan waktu sekaligus lebih rumit.
•
Oracle Data Miner memiliki dokumentasi yang lengkap sehingga orang awam
dapat meraih informasi dengan lebih mudah. Hal ini berbeda dengan SAS
Enterprise Miner dan SPSS Clementine, dimana informasi sedikit sulit untuk
ditemukan.
•
PT. Enseval Putera M egatrading sudah memiliki DBMS Oracle sehingga lebih
mudah menggunakan Oracle Data Miner karena tingkat integrasinya lebih tinggi
daripada menggunakan SAS atau SPSS.
147
•
Keuntungan lainnya adalah object yang terbentuk dalam Oracle Data Miner
terwujud dalam bentuk package. Jadi apabila ingin membuat aplikasi yang ingin
disesuaikan dengan kebutuhan, maka dapat menggunakan package yang bernama
DBM S_DATA_M INING.
4.3
Tahapan dalam Proses Data Mining
4.3.1
Business Understanding
Tahap awal dari perancangan data mining ini berfokus pada pemahaman
mengenai tujuan dan masalah dari bisnis PT. Enseval Putera M egatrading. Tahap ini
penting dilakukan agar dapat mengubah pengetahuan yang diperoleh menjadi suatu
definisi masalah data mining, dan merancang rencana awal untuk mencapai tujuan PT.
Enseval Putera M egatrading. M emahami tujuan perusahaan dengan benar sangat
dibutuhkan untuk memastikan bahwa perancangan data mining yang dilakukan akan
menghasilkan informasi dan pengetahuan yang tepat sebagai jawaban dari permasalahan
yang dihadapi PT. Enseval Putera M egatrading.
Dalam menentukan tujuan bisnis PT. Enseval Putera M egatrading, diperlukan
pemahaman mengenai perusahaan terlebih dahulu yang telah dilakukan pada bab tiga
mengenai analisis perusahaan dan sistem yang berjalan. Analisis perusahaan dimulai
dengan mengetahui latar belakang serta visi misi yang dimiliki oleh PT. Enseval Putera
M egatrading (Lihat subbab 3.1.1 dan 3.1.2). Hal ini dilakukan untuk mengetahui tujuan
yang ingin dicapai oleh perusahaan, sumber daya yang dimiliki dan faktor penting yang
diutamakan oleh perusahaan. Selanjutnya, struktur organisasi digambarkan untuk
mengidentifikasi divisi dan departemen dalam perusahaan (Lihat subbab 3.1.3). Struktur
organisasi perusahaan dibutuhkan untuk mengidentifikasi unit bisnis yang terkena
148
dampak perancangan data mining yang merupakan daerah permasalahan, contohnya
bagian finance dan accounting, bagian penjualan dan sebagainya. Selain itu dilakukan
pula identifikasi peran bisnis yang dimiliki masing-masing bagian untuk mengetahui
pihak utama atau pihak yang berwenang untuk menggunakan hasil perancangan data
mining (Lihat subbab 3.1.4).
Analisis lebih lanjut dilakukan dengan menganalisis kondisi internal dan
eksternal PT. Enseval Putera M egatrading untuk mengidentifikasi kekuatan, kelemahan,
peluang dan ancaman terhadap perusahaan yang akan digunakan dalam menyusun
strategi perusahaan untuk mencapai tujuan perusahaan (Lihat subbab 3.2). Keseluruhan
strategi PT. Enseval Putera M egatrading.dipaparkan dalam matrik analisis SWOT pada
Tabel 3.1. Untuk menentukan strategi yang akan dilaksanakan oleh perusahaan,
dilakukan perhitungan IFAS dan EFAS yang menghasilkan kuadran posisi PT. Enseval
Putera M egatrading (Lihat Gambar 3.4). Di sisi lain, juga dilakukan analisis mengenai
sistem yang sedang berjalan serta masalah-masalah yang dihadapi dalam memenuhi
persyaratan bisnis perusahaan (Lihat subbab 3.3 dan 3.5). Berdasarkan tujuan dan
masalah yang dihadapi tersebut, maka dapat dianalisis kebutuhan informasi yang
dibutuhkan perusahaan untuk mengatasi masalah tersebut (Lihat Tabel 3.19). Berikut
adalah penjabaran kebutuhan informasi yang akan dihasilkan dari perancangan aplikasi
analytical CRM ini :
•
Informasi mengenai pola pembelian pelanggan yang dapat mendukung kesempatan
untuk melakukan cross-selling mengenai produk yang dapat dikombinasikan.
•
Informasi mengenai perbandingan volume penjualan dengan pesaing untuk
meningkatkan market share.
149
•
Informasi mengenai pola pembayaran pelanggan untuk dapat menentukan promosi
atau diskon serta Term of Payment yang tepat berdasarkan kemampuan pelanggan.
•
Informasi mengenai prediksi ketepatan waktu pembayaran pelanggan di masa yang
akan datang
Selanjutnya, permasalahan bisnis yang ada akan diterjemahkan menjadi salah
satu bentuk permasalahan yang dapat diselesaikan melalui data mining. Untuk
menghasilkan informasi mengenai perbandingan volume penjualan dengan pesaing,
dapat diselesaikan tanpa menggunakan teknik data mining tertentu. Sehingga untuk
menghasilkan informasi ini tidak akan dilakukan proses data mining. Sedangkan untuk
ketiga kebutuhan informasi lainnya akan dihasilkan dengan menggunakan teknik data
mining. Tabel 4.2 menjabarkan tujuan data mining serta bentuk permasalahan data
mining yang akan diselesaikan.
Tabel 4.2 Tujuan, Kebutuhan Informasi dan Permasalahan Data mining
Tujuan Bisnis
M eningkatkan
profitabilitas pelanggan
dalam penjualan produk
dengan penawaran yang
menarik sesuai dengan
kebutuhan pelanggan
Analisis Masalah
Kebutuhan Informasi
Kondisi lapangan yang
tidak menentu
mempengaruhi jumlah
kunjungan salesforce
ke outlet
Informasi mengenai pola
pembelian pelanggan yang
dapat mendukung
kesempatan untuk
melakukan cross-selling
mengenai produk yang dapat
dikombinasikan
Beberapa jenis produk
tidak laku di pasaran
M engakuisisi pelanggan
yang potensial melalui
pengelolaan pembayaran
yang efektif dan optimal
Permasalahan
Data mining
Affinity Grouping
Algoritma Data
mining
Association Rules
- Apriori
Tidak sesuainya Term
of Payment pelanggan
dengan pelaksanaan
Informasi mengenai pola
Clustering
pembayaran pelanggan untuk
dapat menentukan promosi
atau diskon serta Term of
Payment yang tepat
berdasarkan kemampuan
pelanggan
Clustering –
K-Means
Kecenderungan
terlambatnya
pembayaran pelanggan
Informasi mengenai prediksi
ketepatan waktu pembayaran
pelanggan di masa yang akan
datang
Predictive
Analytics
Prediction
151
4.3.2
Data Understanding
Setelah permasalahan bisnis diformulasikan menjadi permasalahan data mining,
langkah berikutnya adalah mengumpulkan dan memilih sumber data yang akan
dijadikan sebagai sumber pembuatan model data mining. Berdasarkan arsitektur
perancangan data mining yang diusulkan (Lihat Gambar 4.1), sumber data yang akan
digunakan dalam proses perancangan data mining diambil dari data mart penjualan dan
data mart penagihan. Untuk lebih jelasnya mengenai skema data mart penjualan dan
penagihan, dapat dilihat pada subbab 3.3, Gambar 3.7 dan Gambar 3.8. Penjelasan
mengenai struktur dan definisi tabel pada skema data mart penjualan dan penagihan
dapat dilihat pada Tabel 3.4 hingga Tabel 3.18.
Untuk data penjualan pesaing, meliputi produk pesaing, nama pesaing, sales
channel pesaing, kota distribusi penjualan pesaing dan data transaksi penjualan pesaing.
Gambar 4.2 menggambarkan skema data pesaing yang akan digunakan.
Gambar 4.2 Skema data penjualan pesaing
152
Berikut ini adalah penjelasan mengenai struktur dan definisi tabel pada skema
eksternal data penjualan pesaing :
Tabel 4.3 M etadata Tabel City
Tabel
Keterangan
City
Tabel ini berisi data mengenai kota distribusi penjualan pesaing PT.
Enseval Putera M egatrading.
Primary Key
City_ID
Foreign Key
No
Nama Field
Tipe Data
Keterangan
Primary Key dengan
1
CITY_ID
Number
format urutan angka
2
CITY_NAM E
Varchar2(100)
Nama kota
Tabel 4.4 M etadata Tabel Competitor
Competitor
Tabel ini berisi data mengenai pesaing PT. Enseval Putera
M egatrading. Atribut yang disimpan berupa deskripsi tentang
pesaing.
Primary Key
Competitor_ID
Foreign Key
No
Nama Field
Tipe Data
Keterangan
Primary Key dengan
1
COM PETITOR_ID
Number
format urutan angka
Tabel
Keterangan
2
COM PETITOR_NAM E
Varchar2(100)
Nama pesaing
Tabel 4.5 M etadata Tabel Sales_Channel
Sales_Channel
Tabel ini berisi data sales_channel yang dimasuki oleh pesaing.
Atribut yang disimpan berupa deskripsi tentang sales channel pesaing.
Primary Key Sales_Channel_ID
Foreign Key
No
Nama Field
Tipe Data
Keterangan
Primary Key dengan
1
SALES_CHANNEL_ID
Number
format urutan angka
Tabel
Keterangan
2
SALES_CHANNEL_DESC
Varchar2(100) Nama Sales Channel
153
Tabel 4.6 M etadata Tabel Item
Item
Tabel ini berisi data mengenai produk yang dimiliki oleh pesaing PT.
Enseval Putera M egatrading. Atribut yang disimpan berupa
keterangan mengenai produk tersebut.
Primary Key Item_Code
Foreign Key
No
Nama Field
Tipe Data
Keterangan
Primary Key dengan format digit pertama
merupakan kode sales channel, digit
kedua dan ketiga merupakan kode dari
1
ITEM _CODE
Varchar2(20)
kelas produk serta dua digit terakhir
merupakan penyingkatan dari nama
produk
Tabel
Keterangan
2
ITEM _DESC
Varchar2(100)
Nama / deskripsi produk
Tabel 4.7 M etadata Tabel Sale
Sale
Tabel ini berisi data mengenai transaksi penjualan pesaing PT.
Enseval Putera M egatrading. Atribut yang disimpan berupa
keterangan transaksi dan foreign key ke tabel lainnya.
Primary Key Sale_ID
Foreign Key Competitor_ID, Sales_Channel_ID, City_ID
No
Nama Field
Tipe Data
Keterangan
Primary Key dengan
1
SALE_ID
Number
format urutan angka
Tabel
Keterangan
2
SALE_DATE
Date
3
COM PETITOR_ID
Number
4
SALES_CHANNEL_ID
Number
5
CITY_ID
Number
6
ITEM _CODE
Varchar2(20)
7
QTY
Number
8
AM OUNT
Number
Tanggal transaksi
Foreign key ke tabel
Competitor
Foreign key ke tabel
Sales_Channel
Foreign key ke tabel
City
Primary Key dan
Foreign key ke tabel
Item
Jumlah produk yang
dibeli
Harga produk yang
dibeli
154
4.3.3
Data Preparation
Pada tahap data preparation, dipilih informasi yang ada di dalam data mart yang
berhubungan dan akan digunakan dalam pembuatan model data mining, yang dapat
berguna bagi perusahaan. Karena model data mining dibuat dengan cara mempelajari
data perusahaan yang ada dan menemukan pola yang tersembunyi, tanpa adanya
penambahan data baru ke dalam data mart, maka pemilihan data ini dapat dilakukan
dengan cara membuat view dari data mart, yang berisi data-data yang akan digunakan.
Untuk membentuk data sumber sesuai dengan field dan format yang dibutuhkan,
diperlukan dua buah view atas data mart penjualan dan satu buah view atas data mart
penagihan. Dua buah view yang diperlukan dari data mart penjualan adalah view yang
akan dijadikan sebagai case table dan nested table sebagai data masukan untuk
melalukan proses mining dengan Association Rules. Sedangkan satu buah view yang
diperlukan dari data mart penagihan akan digunakan untuk membuat model untuk
menemukan pola pembayaran pelanggan dengan Clustering.
•
View vSalesM odel
View vSalesM odel merupakan view yang dibuat dari tabel fakta EPM _Sales_Qty_F
dan beberapa dimensinya pada data mart penjualan. vSalesM odel dibuat untuk
mendukung analisis penjualan dalam menemukan pola pembelian pelanggan serta
hubungan produk yang sering dibeli oleh pelanggan secara bersamaan. View
vSalesM odel akan dijadikan sebagai case table dalam penggunaan algoritma
Association Rules. Case table yang akan dirancang berisi atribut-atribut key fakta
EPM _Sales_Qty_F yang akan digunakan sebagai Case_ID, serta atribut-atribut
pelanggan yang melakukan transaksi. Berikut adalah SQL pembuatan view
vSalesM odel :
155
CREATE OR REPLACE VIEW vSalesM odel
AS
SELECT
F.Product_Key, Rayon_Principal_Key, Geography_Key,
SDD.Sales_Dept_Key, SCD.Sales_Channel_Key,
BD.Branch_Key, DTD.Date_Time_Key, Trans_Type_Key,
Rayon_Key, CDD.Channel_Dist_key, Company_Key,
Branch_Name, Sales_Directorate_Desc, Channel_Dist_Desc,
Customer_Name, Customer_Category, Sales_Channel_Desc,
City_Name, Principal_Desc
FROM
EPM _Sales_Qty_F F, Sales_Channel_Dim SCD,
Branch_Dim BD, Sales_Dept_Dim SDD, Product_Dim PD
Channel_Dist_Dim CDD, Date_Time_Dim DTD
WHERE
F.Sales_Channel_Key = SCD.Sales_Channel_Key
AND F.Branch_Key = BD.Branch_Key
AND F.Sales_Dept_Key = SDD.Sales_Dept_Key
AND F.Channel_Dist_Key = CDD.Channel_Dist_Key
AND F.Date_Time_Key = DTD.Date_Time_Key
AND F.Product_Key = PD.Product_Key;
Tabel 4.8 M etadata View vSalesM odel
Nama Field
Product_Key
Rayon_Principal_Key
Field Sumber
Product_Key
Rayon_Principal_Key
Tabel S umber
EPM _Sales_Qty_F
EPM _Sales_Qty_F
Geography_Key
Geography_Key
EPM _Sales_Qty_F
Sales_Dept_Key
Sales_Dept_Key
EPM _Sales_Qty_F
Sales_Channel_Key
Sales_Channel_Key
EPM _Sales_Qty_F
Branch_Key
Date_Time_Key
Branch_Key
Date_Time_Key
EPM _Sales_Qty_F
EPM _Sales_Qty_F
Trans_Type_Key
Trans_Type_Key
EPM _Sales_Qty_F
Rayon_Key
Channel_Dist_key
Rayon_Key
Channel_Dist_key
EPM _Sales_Qty_F
EPM _Sales_Qty_F
Company_Key
Company_Key
EPM _Sales_Qty_F
Branch_Name
Sales_Directorate_Desc
Channel_Dist_Desc
Customer_Name
Customer_Category
Sales_Channel_Desc
City_Name
Principal_Desc
Branch_Name
Sales_Directorate_Desc
Channel_Dist_Desc
Customer_Name
Customer_Category
Sales_Channel_Desc
City_Name
Principal_Desc
Branch_Dim
Sales_Dept_Dim
Channel_Dist_Dim
Sales_Channel_Dim
Sales_Channel_Dim
Sales_Channel_Dim
Sales_Channel_Dim
Product_Dim
Keterangan
Key Product (digunakan sebagai case ID)
Key Rayon_Principal (digunakan sebagai
case ID)
Key Geography (digunakan sebagai case
ID)
Key Sales_Dept (digunakan sebagai case
ID)
Key Sales_Channel (digunakan sebagai
case ID)
Key Branch (digunakan sebagai case ID)
Key Date_Time (digunakan sebagai case
ID)
Key Trans_Type (digunakan sebagai case
ID)
Key Rayon (digunakan sebagai case ID)
Key Channel_dist (digunakan sebagai
case ID)
Key Company (digunakan sebagai case
ID)
Nama cabang
Deskripsi direktorat salesman
Nama channel distribusi
Nama customer
Kategori customer
Nama sales channel
Nama kota customer
Nama principal pemilik produk
157
•
View vNestedSales
View vNestedSales merupakan view yang dibuat berdasarkan vSalesM odel untuk
mentransformasikan kumpulan produk yang dibeli menjadi bentuk single-record.
View ini akan dijadikan sebagai nested table yang diperlukan sebagi masukan data
pada algoritma Association Rules. Berikut adalah SQL pembuatan view
vNestedSales:
CREATE OR REPLACE VIEW vNestedSales
AS
SELECT CASE_ID,
CAST(COLLECT(DM _Nested_Numerical(NAM E, VALUE)) AS
DM _Nested_Numericals) SALES_ITEM S
FROM
(
SELECT CASE_ID,
CAST(ITEM _DESC AS VARCHAR2(4000)) as NAM E,
1 as VALUE
FROM
PRODUCT_DIM,
(
SELECT
PRODUCT_KEY, BRANCH_KEY,
CHANNEL_DIST_KEY, COM PANY_KEY,
DATE_TIM E_KEY, GEOGRAPHY_KEY,
RAYON_KEY, RAYON_PRINCIPAL_KEY,
SALES_CHANNEL_KEY, SALES_DEPT_KEY,
TRANS_TYPE_KEY, DENSE_RANK() OVER
(ORDER BY BRANCH_KEY,
CHANNEL_DIST_KEY, COM PANY_KEY,
DATE_TIM E_KEY, GEOGRAPHY_KEY,
RAYON_KEY, RAYON_PRINCIPAL_KEY,
SALES_CHANNEL_KEY, SALES_DEPT_KEY,
TRANS_TYPE_KEY
) CASE_ID
FROM vsalesmodel
)SUB
WHERE PRODUCT_DIM .PRODUCT_KEY = SUB.PRODUCT_KEY
)ITEM S
GROUP BY CASE_ID;
158
Tabel 4.9 M etadata View vNestedSales
Nama Field
•
Field Sumber
Tabel S umber
Case_ID
-
EPM _Sales_Qty_F
Keterangan
M erupakan hasil
rownum
Sales_Items
Item_Desc
Product_Dim
Nama produk
View vCollectionM odel
View
vCollectionM odel
EPM _AR_Transaction _F,
merupakan
view
yang dibuat
dari
tabel
fakta
EPM _AR_Paycash _F, EPM _AR_PayGiro _F dan
beberapa dimensinya pada data mart penagihan. vCollectionM odel dibuat untuk
mendukung analisis pelanggan dalam menemukan pola pembayaran pelanggan
berdasarkan waktu pembayaran, jenis pembayaran dan tanggal jatuh tempo
pembayaran. Dalam pembentukan view ini juga dipertimbangan parameter grace day
yang merupakan lama hari yang ditolerir oleh perusahaan dalam keterlambatan
pembayaran. Secara default, lama hari grace day yang diberikan perusahaan adalah
tiga hari, namun ada kemungkinan dapat berubah jika perusahaan ingin memberikan
tambahan hari grace day kepada pelanggan. Berikut adalah SQL pembuatan
procedure untuk membuat view vCollectionM odel :
159
CREATE OR REPLACE PROCEDURE collection_proc
(condition VARCHAR2 DEFAULT ' ', graceDay NUM BER DEFAULT 3)
AS
BEGIN
EXECUTE IMMEDIATE
'CREATE OR REPLACE VIEW VCOLLECTIONM ODEL
AS
SELECT DISCTINCT customer_name, city_name, calendar_dt as
transaction_date, payment_term, t.trx_number, t.trx_amount,
CASE WHEN t.trx_number = paycash.trx_number THEN ''CASH''
ELSE ''GIRO''
END payment_type,
CASE WHEN t.trx_number = paycash.trx_number THEN
paycash.payment_date
ELSE paygiro.payment_date
END payment_date,
CASE WHEN t.trx_number = paycash.trx_number THEN
CASE WHEN (TO_DATE(paycash.payment_date,''DD-MONYYYY'') > TO_DATE((calendar_dt +
payment_term),''DD-MON-YYYY'')) THEN ''LATE ''
ELSE ''ONTIM E'' END
ELSE
CASE WHEN (TO_DATE(paygiro.payment_date,''DD-MONYYYY'') > TO_DATE((calendar_dt +
payment_term),''DD-MON-YYYY''))THEN ''LATE ''
ELSE ''ONTIM E'' END
END payment_status,
CASE WHEN t.trx_number = paycash.trx_number THEN
CASE WHEN (TO_DATE(paycash.payment_date,''DD-MONYYYY'') > TO_DATE((calendar_dt + payment_term + ' ||
graceDay || '),''DD-M ON-YYYY'')) THEN
TO_DATE(paycash.payment_date,''DD-MON-YYYY'') TO_DATE(calendar_dt + payment_term + ' || graceDay ||
',''DD-M ON-YYYY'')
ELSE 0 END
ELSE
CASE WHEN (TO_DATE(paygiro.payment_date,''DD-MONYYYY'') > TO_DATE((calendar_dt + payment_term + ' ||
graceDay || '),''DD-M ON-YYYY'')) THEN ''LATE '' ||
TO_CHAR(TO_DATE(paygiro.payment_date,''DDMON-YYYY'') - TO_DATE(calendar_dt + payment_term
+ ' || graceDay || ',''DD-M ON-YYYY'')) || '' DAY''
ELSE ''ONTIM E'' END
END payment_status_detail
160
FROM
sales_channel_cust_dim s,
sales_dept_dim dept,
branch_dim b,
date_time_dim d,
epm_ar_transaction_f t,
(
SELECT p.trx_number, dt.calendar_dt as payment_date
FROM date_time_dim dt, epm_ar_paycash_f p
WHERE dt.date_time_key = p.date_time_key
) paycash ,
(
SELECT trx_number, calendar_dt as payment_date
FROM date_time_dim dt, epm_ar_paygiro_f x
WHERE dt.date_time_key = x.date_time_key
) paygiro
WHERE
s.sales_channel_cust_key = t.sales_channel_cust_key
AND d.date_time_key = t.date_time_key
AND dept.sales_dept_key = t.sales_dept_key
AND b.branch_key = t.branch_key
AND (paygiro.trx_number = t.trx_number
OR paycash.trx_number = t.trx_number) '
|| condition || '
ORDER BY t.trx_number';
END;
Tabel 4.10 M etadata View vCollectionM odel
Nama Field
Customer_Name
City_Name
Transaction_Date
Payment_Term
Trx_Number
Trx_Amount
Payment_Type
Field Sumber
Customer_Name
City_Name
Calendar_dt
Payment_Term
Trx_Number
Trx_Amount
-
Tabel S umber
Sales_Channel_Cust_Dim
Sales_Channel_Cust_Dim
Date_Time_Dim
EPM _AR_Transaction_F
EPM _AR_Transaction_F
EPM _AR_Transaction_F
EPM _AR_Transaction_F
EPM _AR_Paycash_F,
EPM _AR_Paygiro_F
Payment_Date
Calendar_dt
Date_Time_Dim,
EPM _AR_Paycash_F,
EPM _AR_Paygiro_F
Payment_Status
-
Date_Time_Dim,
EPM _AR_Paycash_F,
EPM _AR_Paygiro_F
Payment_Status_Detail
-
Date_Time_Dim,
EPM _AR_Paycash_F,
EPM _AR_Paygiro_F
Keterangan
Nama customer
Nama kota
Tanggal transaksi
Jatuh tempo dalam hari
Nomor dokumen faktur
Nilai dokumen
Jenis pembayaran berupa “CASH” atau
“GIRO”, diperoleh dari pencarian
trx_number yang ada di
EPM _AR_Transaction_F ada di tabel
EPM _AR_Paycash_F (cash) atau
EPM _AR_Paygiro_F (giro)
Tanggal pembayaran, diperoleh dari field
calendar_dt hasil penggabungan
date_time_key pada date_time_dim dengan
EPM _AR_Paycash_F atau
EPM _AR_Paygiro_F
Status pembayaran berupa “ONTIM E” atau
“LATE”, diperoleh dari hasil perbandingan
transaction_date + payment_term + grace
day dengan payment_date. Grace day
adalah parameter jumlah hari terlambat
yang ditolerir perusahaan.
Jumlah hari terlambat pembayaran,
diperoleh dari hasil perbandingan
transaction_date + payment_term + grace
day dengan payment_date.
162
Selain ketiga view diatas, juga dibuat sebuah tabel yang akan digunakan untuk
menyimpan parameter-parameter yang akan digunakan untuk membuat model data
mining. Tabel ini akan digunakan setiap kali membuat model data mining. Tabel 4.11
menggambarkan stuktur tabel yang akan dibangun :
Tabel 4.11 M etadata Tabel V_Build_Setting
No
1
2
4.3.4
Nama Field
Tipe Data
SETTING_NAM E
Varchar2(30)
Keterangan
Nama parameter
setting
SETTING_VALUE
Varchar2(128)
Nilai parameter setting
Modelling
4.3.4.1 Association Rules
Pada tahap perancangan ini dilakukan pembuatan model data mining sesuai
dengan algoritma yang akan digunakan. M odel yang akan dibuat bertujuan untuk
menemukan pola pembelian pelanggan serta hubungan antara produk yang dibeli secara
bersamaan oleh pelanggan. Fungsi data mining yang digunakan adalah Association
Rules dan algoritma yang digunakan untuk mendukung fungsi ini adalah algoritma
Apriori. Tabel 4.12 dan Tabel 4.13 menunjukkan spesifikasi dari struktur model data
mining yang akan dibangun dan parameter yang digunakan.
Tabel 4.12 Spesifikasi Struktur M odel Association Rules yang dibangun
Nama Field
Product_Key
Rayon_Principal_Key
Geography_Key
Sales_Dept_Key
Sales_Channel_Key
Branch_Key
Date_Time_Key
Trans_Type_Key
Rayon_Key
Channel_Dist_key
Company_Key
Sales_Items
Key
X
X
X
X
X
X
X
X
X
X
X
Input
X
Data Type
Number
Number
Number
Number
Number
Number
Number
Number
Number
Number
Number
Varchar2
Mining Type
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Numerical
Categorical
Keterangan
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
Field ini merupakan case key
M erupakan nama dari produk yang akan
dikombinasikan
Tabel 4.13 Spesifikasi Parameter M odel Association Rules yang dibangun
Nama Parameter
M inimum_Support
Nilai Parameter
5
Keterangan
Persentase jumlah kemunculan minimal itemset untuk mendukung setiap pola
aturan
M inimum_Confidence
10
Persentase nilai minimal hubungan antara item dalam setiap pola aturan
Algorithm_Name
ALGO_APRIORI Nama algoritma yang digunakan
M aximum_Rule_Length
3
Jumlah maksimum kombinasi item dalam setiap pola
164
Berdasarkan Tabel 4.13, parameter minimum_support menentukan persentase
minimum jumlah kemunculan itemset untuk mendukung kemunculan suatu pola aturan.
Parameter minimum_confidence menentukan merupakan persentase nilai intensitas
minimum dimana suatu produk dibeli bersamaan dengan produk lain dalam waktu yang
bersamaan.
Nilai yang diberikan untuk kedua parameter tersebut harus disesuaikan dengan
jumlah data sumber yang digunakan untuk pemrosesan data mining. Berikut ini
beberapa ketentuan yang harus diperhatikan dalam menentukan nilai parameter
minimum_support :
•
Semakin kecil nilai support, semakin banyak kapasitas memory yang dibutuhkan
dan semakin lama waktu pemrosesan karena data yang terlibat dalam proses
pembentukan pola semakin banyak.
•
Semakin besar nilai support, semakin sedikit kapasitas memory yang dibutuhkan
dan semakin cepat pemrosesan, namun lebih sedikit pola aturan yang
teridentifikasi karena semakin sedikit data yang terlibat dalam pencarian pola.
Beberapa ketentuan yang harus diperhatikan dalam menentukan nilai parameter
minimum_ confidence, antara lain:
•
Semakin kecil nilai confidence, semakin banyak rule yang tidak berguna akan
teridentifikasi dalam pemrosesan data, sehingga menyebabkan nilai confidence
dari setiap pola yang dihasilkan semakin rendah.
•
Semakin besar nilai confidence, semakin sedikit rule yang tidak berguna akan
teridentifikasi dalam pemrosesan data, sehingga menyebabkan rule yang
mungkin berguna tidak teridentifikasi.
165
Untuk parameter minimum_support, nilai yang ditetapkan sebesar 5. Nilai ini
merupakan nilai default dari Oracle Data Miner yang telah teruji sebagai nilai optimal
untuk mendukung waktu pemrosesan data yang relatif cepat. Untuk parameter
minimum_confidence, nilai yang ditetapkan sebesar 10, karena nilai ini merupakan nilai
default dari Oracle Data Miner yang telah teruji sebagai nilai optimal untuk
menghasilkan rule yang berguna. Untuk parameter Maximum_Rule_Length, nilai yang
ditetapkan sebesar tiga, yaitu menunjukkan kombinasi tiga buah item yang ingin
ditemukan.
Nilai – nilai parameter tersebut akan disimpan ke dalam tabel v_build setting
yang akan digunakan untuk pemrosesan pembuatan model data mining nantinya. Berikut
adalah query PL/SQL untuk menyimpan nilai parameter setting tersebut.
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''ASSO_M IN_SUPPORT'','' ' || support || ' '')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''ASSO_M IN_CONFIDENCE'','' ' || confidence ||' '')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''ALGO_NAM E'',''ALGO_APRIORI_ASSOCIATION_RULES'')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''ASSO_M AX_RULE_LENGTH'','' ' || rule || ' '')';
Berikut ini query DM X yang dijalankan untuk pembuatan model data mining
Association Rules :
DBM S_DATA_M INING.CREATE_M ODEL(
model_name
=> model_name ,
mining_function
=> DBM S_DATA_M INING.ASSOCIATION,
data_table_name
=> 'vNestedSales',
case_id_column_name => 'CASE_ID',
target_column_name => NULL,
data_schema_name
=> 'ENSEVAL',
settings_schema_name => 'ENSEVAL',
settings_table_name
=> 'v_build_setting');
166
Gambar 4.3 merupakan contoh tampilan pola-pola yang dihasilkan dari model
Association Rules yang telah dibangun :
Gambar 4.3 Contoh Pola-Pola Aturan yang Dihasilkan M odel Association Rules
Hasil pola diatas menunjukkan aturan asosisasi produk yang dibeli oleh
pelanggan berdasarkan sales channel, principal dan branch perusahaan. Pola aturan
yang dihasilkan menunjukkan produk yang menjadi leading yang ditunjukkan pada
bagian if (condition), dan pasangan produk yang direkomendasikan untuk dibeli
bersamaan yang ditunjukkan pada bagian Then (association) (Lihat Gambar 4.3). Setiap
aturan asosiasi yang dihasilkan memiliki nilai support dan confidence yang ditunjukkan
dalam bentuk persentase untuk mengetahui seberapa baik aturan asosiasi tersebut dan
rapa sering aturan asosiasi tersebut terjadi. Hal ini akan mendukung pengambilan
keputusan dalam menentukan aturan asosiasi yang baik untuk diterapkan untuk
menawarkan produk kepada pelanggan.
167
4.3.4.2 Clustering
Untuk membuat model yang akan digunakan untuk mengetahui pola-pola
pembayaran pelanggan berdasarkan detail pembayaran pelanggan, fungsi data mining
yang digunakan adalah Clustering. Algoritma yang digunakan untuk menjalankan fungsi
ini adalah algoritma K-Means. Hasil pola cluster yang dihasilkan model clustering ini
menunjukkan
pengelompokkan
perilaku
pembayaran
pelanggan
berdasarkan
payment_term, payment_type dan payment_status dari semua transaksi histori
pembayaran pelanggan. Setiap cluster yang dihasilkan memiliki tingkat kepadatan yang
dimiliki di dalam cluster, yaitu banyaknya pelanggan yang memiliki pola perilaku
pembayaran yang sama. Dari hasil clustering ini, perusahaan dapat mengetahui
kecenderungan perilaku pembayaran pelanggan dan seberapa sering hal itu akan terjadi.
Hasil pola clustering ini akan berguna bagi perusahaan dalam menentukan Term
of Payment yang tepat bagi pelanggan serta jenis pembayaran yang paling cocok untuk
pelanggan. Selain itu, semua histori pembayaran pelanggan meliputi banyaknya
transaksi, jumlah keterlambatan per transaksi serta total pembayaran yang harus dibayar
oleh pelanggan akan diinformasikan untuk mendukung perusahaan menganalisa
seberapa baik pembayaran yang dilakukan pelanggan. Total pembayaran pelanggan
yang terlambat berguna bagi perusahaan untuk mengetahui kemampuan pembayaran
pelanggan serta jumlah bunga yang seharusnya diperoleh perusahaan apabila telah
dilunasi oleh pelanggan tepat pada waktunya.
Tabel 4.14 dan Tabel 4.15 menunjukkan spesifikasi dari struktur model data
mining yang akan dibangun dan parameter yang digunakan.
Tabel 4.14 Spesifikasi Struktur M odel Clustering yang dibangun
Nama Field
Case_ID
Payment_Status
Key
X
Input
X
Data Type
Number
Varchar2
Mining Type
Numerical
Categorical
Payment_Term
X
Number
Categorical
Payment_Type
X
Varchar2
Categorical
Keterangan
Digunakan sebagai case key
Digunakan sebagai masukan untuk
pengelompokkan cluster
Digunakan sebagai masukan untuk
pengelompokkan cluster
Digunakan sebagai masukan untuk
pengelompokkan cluster
Tabel 4.15 Spesifikasi Parameter M odel Clustering yang dibangun
Nama Parameter
M ax_Number_Clusters
Algorithm_Name
Split_Criterion
Distance
Nilai Parameter
10
ALGO_KM EANS
VARIANCE
EUCLIDEAN
Keterangan
Jumlah cluster maksimal yang akan dihasilkan
Nama algoritma yang digunakan
Kriteria yang digunakan untuk membagi cluster
Ukuran untuk menentukan kemiripan data dalam cluster
169
Berdasarkan Tabel 4.15, parameter Max_Number_Clusters menentukan jumlah
maksimal cluster yang akan dihasilkan dari model data mining yang dibuat. Parameter
Split_Criterion
menentukan
metode
yang
digunakan
untuk
membagi
dan
menggabungkan suatu case ke menjadi suatu cluster tertentu. Parameter Distance
menentukan bagaimana kemiripan antara elemen-elemen dapat dihitung.
Semua parameter diatas akan mempengaruhi hasil pengelompokkan data ke
dalam cluster tertentu. Berikut ini beberapa ketentuan yang harus diperhatikan dalam
menentukan nilai parameter Max_Number_Clusters :
•
Semakin besar nilai Max_Number_Clusters akan menghasilkan semakin banyak
cluster. Hal ini mengakibatkan semakin rendahnya kemiripan data di dalam
cluster dan semakin rendahnya perbedaan antar cluster karena terpecah menjadi
lebih banyak.
•
Semakin kecil nilai Max_Number_Clusters akan menghasilkan semakin sedikit
cluster. Hal ini mengakibatkan data dalam setiap cluster menjadi semakin mirip
dan perbedaan antar cluster menjadi lebih besar. Hal ini akan membuat kualitas
analisis cluster dianggap menjadi semakin baik.
Untuk parameter nilai Max_Number_Clusters, nilai yang ditetapkan sebesar 10. Nilai ini
merupakan nilai default dari Oracle Data Miner yang telah teruji sebagai nilai optimal
untuk menemukan jumlah cluster dengan karakteristik yang mirip.
Untuk menentukan parameter Split_Criterion, terdapat dua buah kriteria yang
disediakan oleh Oracle Data Miner, yaitu : Cluster Variance dan Cluster Size. Cluster
Variance adalah dispersi komputasi dari titik-titik di sekitar pusat cluster dan mewakili
ukuran seberapa baik pusat cluster "cocok" dengan titik-titik tersebut. Hal ini dihitung
dengan menghitung jarak dari setiap titik dari pusat cluster. Cluster dengan dispersi
170
terbesar dipilih sebagai kandidat pemecah (split). Cluster Size hanya merupakan
hitungan jumlah titik dalam sebuah cluster. Cluster dengan jumlah titik terbesar adalah
kandidat pemecah (split). Kriteria yang dipilih untuk model yang dibuat adalah Cluster
Variance. Nilai ini merupakan nilai default dari Oracle Data Miner yang telah teruji
sebagai nilai optimal untuk menentukan pembagian cluster.
Untuk menentukan parameter Distance, terdapat dua ukuran yang disediakan
oleh Oracle Data M iner, yaitu : Euclidean dan Cosine. Ukuran Cosine lebih cocok
digunakan apabila data telah dinormalisasi. Ukuran distance yang dipilih untuk
membuat model clustering ini adalah Euclidean. Nilai ini merupakan nilai default dari
Oracle Data Miner yang telah teruji sebagai nilai optimal untuk menghitung kemiripan
antara elemen-elemen data.
Nilai – nilai parameter tersebut akan disimpan ke dalam tabel v_build setting
yang akan digunakan untuk pemrosesan pembuatan model data mining nantinya. Berikut
adalah query PL/SQL untuk menyimpan nilai parameter setting tersebut.
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''CLUS_NUM _CLUSTERS'', ''10'')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''ALGO_NAM E'', ''ALGO_KM EANS'')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''KMNS_SPLIT_CRITERION'', ''KM NS_VARIANCE'')';
EXECUTE IMMEDIATE 'INSERT INTO v_build_setting VALUES
(''KMNS_DISTANCE'', ''KM NS_EUCLIDEAN'')';
Berikut ini query DMX yang dijalankan untuk pembuatan model data mining
Clustering :
171
DBM S_DATA_M INING.CREATE_M ODEL(
model_name
=> model_name,
mining_function => dbms_data_mining.clustering,
data_table_name => 'vCollectionM odel',
case_id_column_name => 'case_id',
settings table name => 'v build setting');
Gambar 4.4 merupakan contoh tampilan pola-pola yang dihasilkan dari model
Clustering yang telah dibangun :
Gambar 4.4 Contoh Pola Cluster yang Dihasilkan M odel Clustering
Selanjutnya setelah model clustering selesai dibangun dan menghasilkan polapola cluster seperti yang ditunjukkan pada Gambar 4.4, pola-pola tersebut akan di-apply
terhadap data pelanggan yang disimpan di database untuk melakukan scoring terhadap
172
masing-masing pelanggan. Dari hasil scoring tersebut akan diketahui pola pembayaran
pelanggan tersebut berdasarkan pola-pola pembayaran yang telah ditemukan.
Untuk melakukan proses scoring ini diperlukan sebuah view yang akan
digunakan untuk menerapkan pola-pola yang dihasilkan dari model clustering terhadap
data pelanggan. View ini akan digenerate oleh Oracle Data Miner berdasarkan model
clustering yang telah dibuat sebelumnya. Berikut adalah query SQL untuk membuat
view tersebut :
CREATE OR REPLACE VIEW v_apply_data
AS
SELECT
ROWNUM AS case_id,
CUSTOM ER_NAM E,
PAYM ENT_STATUS,
TO_CHAR(PAYM ENT_TERM ) AS PAYM ENT_TERM ,
PAYM ENT_TYPE
FROM vCollectionM odel;
Berikut ini query DM X yang dijalankan untuk menerapkan hasil model data mining
Clustering :
DBM S_DATA_M INING.APPLY (
model_name
=> model_name,
data_table_name
=> 'v_apply_data',
case_id_column_name
=> 'case_id',
result_table_name
=> result_table_name,
data_schema_name
=> 'ENSEVAL');
Gambar 4.5 merupakan contoh tampilan hasil penerapan pola-pola yang
dihasilkan dari model Clustering terhadap data pelanggan :
173
Gambar 4.5 Contoh Hasil Scoring Pola Cluster
4.3.4.3 Predictive Analytics
Untuk memprediksi perilaku pelanggan di masa yang akan datang terutama
mengenai perilaku pembayaran pelanggan yang telah ditemukan dengan teknik
clustering, maka dapat dilakukan dengan menggunakan Predictive Analytics. Hasil
scoring pola pembayaran pelanggan yang disimpan data view v_apply_data digunakan
untuk melakukan prediksi pola pembayaran pelanggan di masa yang akan datang
Berikut adalah query SQL untuk membuat view sementara yang akan digunakan sebagai
masukan untuk melakukan fungsi prediksi tersebut :
CREATE OR REPLACE VIEW vTemp
AS
SELECT a.case_id, cluster_ID, customer_name
FROM resultTableName r, v_apply_data a
WHERE a.case_id = r.case_id
ORDER BY cluster_id';
174
Berikut ini query DM X yang dijalankan untuk memprediksi hasil scoring model
data mining Clustering :
DBM S_PREDICTIVE_ANALYTICS.PREDICT(
accuracy
=> v_accuracy,
data_table_name
=> 'vTemp',
case_id_column_name
=> 'cluster_id',
target_column_name
=> 'customer_name',
result_table_name
=> 'predict_result');
Gambar 4.6 merupakan contoh tampilan hasil prediksi pola-pola yang dihasilkan
dari Predictive Analysis :
Gambar 4.6 Contoh Hasil Prediksi Hasil Scoring Pola Cluster
Tingkat probability yang dimiliki setiap cluster seperti yang ditunjukkan pada
Gambar 4.6 diatas menunjukkan nilai prediksi kemungkinan pelanggan berada di dalam
cluster tersebut. Hal ini akan berguna bagi perusahaan sebagai bahan pertimbangan
dalam menentukan Term of Payment yang paling tepat untuk pelanggan. Setiap
pelanggan dapat menjadi anggota dari satu cluster atau lebih, hal ini bergantung pada
pola cluster yang dihasilkan pada model clustering sebelumnya. Perbandingan
probability antar cluster yang dimiliki pelanggan akan memperlihatkan kecenderungan
perilaku pembayaran pelanggan di masa yang akan datang.
175
4.3.5
Evaluate
Tahap selanjutnya setelah membuat model data mining adalah melakukan
evaluasi atas hasil yang diperoleh. Evaluasi ini dilakukan untuk memastikan bahwa
model yang dibuat menghasilkan informasi yang berguna sesuai tujuan yang ingin
dicapai.
Berdasarkan model data mining yang telah dibuat, ditemukan sedikit perbaikan
untuk parameter minimum_support pada model Association Rules. Perbaikan ini
disebabkan karena data transaksi penjualan yang dimiliki perusahaan memiliki lini
produk yang sangat luas, contohnya : obat – obatan, bahan kimia, suplemen makanan,
produk konsumsi seperti susu dan lain-lain. Hal ini mengakibatkan tidak semua produk
tersebut dapat dikombinasikan dan mengakibatkan kecilnya angka support yang terjadi,
karena angka support adalah perbandingan dengan keseluruhan transaksi yang dimiliki
dalam data. Apabila nilai parameter minimum_support tidak diubah maka pola aturan
kombinasi produk yang dihasilkan sangatlah sedikit bahkan tidak ada karena tidak
memenuhi syarat minimal terjadinya jumlah kemunculkan itemset dari keseluruhan
jumlah transaksi. Tabel 4.16 menjelaskan perbaikan parameter minimum_support yang
dilakukan.
Tabel 4.16 Revisi Spesifikasi Parameter M odel Association Rules
Nilai Awal Parameter
Nilai Revisi Parameter
M inimum_Support
5
1
4.3.6
Nama Parameter
Deployment
Pada tahap ini akan dilakukan perancangan aplikasi berbasis web yang dapat
digunakan oleh para eksekutif perusahaan untuk membuat dan melihat model dalam
176
data mining. Aplikasi ini akan dirancang dengan menggunakan ASP.Net, Dundas Map,
DevExpress dan Ajax ToolKit.
4.3.6.1 Use Case Diagram
Berikut ini use case diagram dari aplikasi berbasis web yang akan dirancang :
Gambar 4.7 Use Case Diagram
177
4.3.6.2 Navigation Diagram
Berikut ini navigation diagram yang menggambarkan struktur alur aplikasi :
Gambar 4.8 Navigation Diagram
178
4.3.6.3 Rancangan Layar Aplikasi
Gambar 4.9 Halaman login
Halaman ini merupakan halaman yang pertama kali muncul ketika user
mengakses aplikasi. Pada halaman ini user dapat melakukan login dengan memasukkan
username dan password kemudian klik tombol login untuk masuk ke halaman home
atau cancel untuk batal.
Gambar 4.10 Halaman change password
Halaman ini berfungsi untuk mengubah password user yang telah melakukan
login terlebih dahulu. Pada halaman ini, user harus memasukkan password lama dan
179
password baru untuk bisa mengubah password. Klik tombol change untuk mengganti
password, dan klik tombol cancel untuk batal.
Gambar 4.11 Halaman home
Pada halaman ini ditampilkan list semua model yang sudah pernah dibuat. Data
yang ditampilkan berupa pembuat (owner), tanggal dibuat (creation date), nama model
(model name), dan
algoritma (algortihm). Untuk melihat detil dari masing-masing
model, user dapat mengklik link detail disebelah kiri model. Detil yang ditampilkan
seperti yang terlihat pada detail list view. Pada halaman ini juga terdapat beberapa link
seperti : cross selling untuk menampilkan halaman yang membangun model cross
selling, customer collection untuk menampilkan halaman yang membangun model yang
memperlihatkan pola pembelian pelanggan, competitor analysist untuk menampilkan
informasi mengenai analisa pesaing-pesaing PT Enseval Putera M egatrading Tbk serta
menu untuk logout.
180
Gambar 4.12 Halaman Selecting data cross selling model
Halaman ini digunakan untuk memilih data-data yang dibutuhkan untuk
membangun model cross selling, seperti : tahun yang dapat dipilih tahun tertentu atau
antara tahun tertentu sampai tahun yang diinginkan, branch name yang dapat dipilih satu
ataupun lebih, berikut pilihan all branch jika ingin menampilkan hasil dari semua
cabang. Sales Channel yang dapat dipilih satu ataupun lebih, berikut pilihan all channel
jika ingin menampilkan hasil dari semua sales channel. Principal yang dapat dipilih satu
ataupun lebih, berikut pilihan all principal jika ingin menampilkan hasil dari semua
principal. Setelah memilih semua data yang diperlukan untuk membangun model,
selanjutnya klik next.
181
Gambar 4.13 Halaman create mining model cross selling
Halaman ini untuk mengatur setting hasil mining model yang akan dibuat. Nama
model merupakan auto generate yang kemudian dapat diedit oleh user. Nama tersebut
digenerate dengan format CS_ddmmyyyy_xx dimana dd merupakan tanggal, mm
merupakan bulan dan yyyy merupakan tahun dimana model tersebut dibuat, dan xx
adalah nomor urut. Selain nama model, pada halaman ini juga tersedia pengaturan
jumlah transaksi (support), kemungkinan terjadi (confidence) serta banyak kemungkinan
(rule) yang dibataskan sampai 4 kemungkinan saja.
Gambar 4.14 Halaman Build & view model
182
Halaman ini merupakan halaman yang menunjukkan bahwa model telah berhasil
dibuat. Pada halaman ini juga ditampilkan detil model yang baru dibangun, seperti
waktu pembuatan dan nama model.
Gambar 4.15 Halaman cross selling model
Halaman ini untuk menampilkan hasil model mining yang telah dibuat. Hasil
mining bisa ditampilkan dengan beberapa filter seperti : jumlah transaksi (support),
kemungkinan terjadi (confidence) dan nama produk. Biarkan textbox jumlah transaksi
dan kemungkinan terjadi kosong dan centang all produk untuk melihat semua data.
Penyaringan data berdasarkan produk dapat dilakukan dengan memilih combo box yang
183
tersedia, kemudian masukkan nama atau kode produk dan tekan tombol search, maka
produk yang telah disaring dapat dipilih pada combo box berikutnya. Selain itu hasil
mining ini dapat ditampilkan dengan urutan jumlah transaksi (support) dan
kemungkinan terjadi (confidence) baik secara ascending maupun descending. Pada
halaman ini juga dapat menghapus model yang telah dibuat dengan menekan tombol
delete. Selain itu, pada halaman ini juga tersedia menu untuk membuat model baru
dengan menekan tombol train model.
Gambar 4.16 Halaman Selecting data customer collection
Halaman ini digunakan untuk memilih data-data yang dibutuhkan untuk
membangun model pola pembayaran customer, seperti : tahun yang dapat dipilih tahun
tertentu atau antara tahun tertenu sampai tahun yang diinginkan, grace day yang
184
merupakan hari toleransi jatuh tempo yang dapat diinput oleh user, branch name yang
dapat dipilih satu ataupun lebih, berikut pilihan all branch jika ingin menampilkan hasil
dari semua cabang. Sales directorat yang dapat dipilih satu ataupun lebih, berikut
pilihan all directorat jika ingin menampilkan hasil dari semua sales directorat.
Gambar 4.17 Halaman create mining model customer collection
Halaman ini digunakan untuk memberi nama model yang akan dibuat. Nama dari
model harus diawali karakter dan tidak boleh mengandung spasi. Panjang dari nama
model tersebut tidak lebih dari 255 karakter.
Gambar 4.18 Halaman Build & view model customer collection
185
Halaman ini merupakan halaman yang menunjukkan bahwa model telah berhasil
dibuat. Pada halaman ini juga ditampilkan detil model yang baru dibangun, seperti
waktu pembuatan, nama model dan jumlah cluster yang telah dibuat.
Gambar 4.19 Halaman customer collection
Halaman ini untuk menampilkan hasil model mining yang telah dibuat. Hasil
mining bisa ditampilkan dengan filter nama pelanggan, Cluster detail yang berisi
penjelasan cluster dan pelanggan yang termasuk dalam cluster. Selain itu, detil transaksi
186
pembayaran pelanggan dan prediksi pola pembayaran pelanggan juga ditampilkan pada
halaman ini. Pada halaman ini juga dapat menghapus model yang telah dibuat dengan
menekan tombol delete. Selain itu, pada halaman ini juga tersedia menu untuk membuat
model baru dengan menekan tombol train model.
Gambar 4.20 Halaman Analisa Pesaing
Halaman ini untuk menampilkan hasil analisa data penjualan dengan pesaing
pada lokasi geografis tertentu. Data ini dapat dilihat berdasarkan harga maupun jumlah
penjualan dari tahun-tahun tertentu berdasarkan sales channel dan produk yang ada. Jika
melihat berdasarkan jumlah penjualan maka akan ditampilkan diagram batang hasil
penjualan PT Enseval Putera M egatrading Tbk dan pesaing-pesaingnya. Jika melihat
187
berdasarkan harga, maka akan ditampilkan diagram garis yang menunjukkan naik
turunnya harga penjualan perusahaan sendiri dan pesaingnya dalam periode tertentu.
4.3.6.4 Arsitektur jaringan komputer
Berikut ini merupakan arsitektur jaringan komputer pada PT Enseval Putera
M egatrading :
Gambar 4.21 Arsitektur Jaringan Komputer
Berdasarkan arsitektur perancangan data mining yang diusulkan (Lihat gambar
4.1), hasil data mining akan ditampilkan melalui suatu portal informasi yaitu website
yang dapat diakses oleh pihak eksekutif perusahaan PT. Enseval Putera M egatrading
melalui jaringan LAN dan WAN. Gambar 4.20 menggambarkan arsitektur jaringan
komputer yang digunakan pada PT. Enseval Putera M egatrading untuk mendukung
akses informasi hasil data mining tersebut.
188
Firewall digunakan untuk melindungi pengaksesan database server oleh user.
User dalam gedung Enseval yang ingin mengakses aplikasi / database server
dihubungkan melalui sebuah switch ataupun access point. User di luar gedung Enseval
dapat terhubung ke database server melalui router.
4.3.6.5 S pesifikasi kebutuhan perangkat keras dan lunak
Berikut ini merupakan spesifikasi minimum perangkat keras dan lunak untuk
Oracle dan ASP.Net yang yang dibutuhkan :
Tabel 4.17 Spesifikasi perangkat keras yang dibutuhkan
Perangkat keras
Processor
Server
Ultra Sparch IV 2.4 GHz
Memory
8 Gbyte
Harddisk
1 Tbyte
NIC
(Network 10/100 M bps
Interface Card)
Client
Intel Pentium 4 1.70
GHz
2 Gbyte
80 GB
10/100 M bps
Tabel 4.18 Spesifikasi perangkat lunak yang dibutuhkan
Perangkat lunak
Operating System
Server
Sun Solaris 9
Database
Management
System
Framework
Browser
Oracle
Server
Database
.NET Framework 3.5
-
Client
M icrosoft Windows
XP Profesional SP2
11g Oracle Database 11g
Client
M ozilla Firefox
Internet Explorer
/