BAB 4 PERANCANGAN, IMPLEMENTAS I DAN EVALUAS I
4.1.
Perancangan Data Warehouse 4.1.1. Memilih Proses (Choosing The Process) Pada Proses ini yang dilakukan adalah menentukan subjek permasalahan yang dihadapi, lalu mengindentifikasi proses bisnis yang berhubungan dengan permasalahan tersebut. Berdasarkan dari hasil analisis dan survey yang telah dilakukan terhadap kegiatan bisnis yang sedang berjalan, maka dapat ditemukan 2 proses yang sangat berkaitan dengan permasalahan yang dihadapi dalam kegiatan operasional seharihari. Kedua proses tersebut adalah: •
Broking
•
Claims
4.1.2. Memilih S umber (Choosing The Grain) Grain adalah data dari calon fakta yang dapat dianalisis. Pemilihan grain berarti memutuskan apa yang akan direpresentasikan oleh record dari tabel fakta. Berikut merupakan grain dalam perancangan data warehouse, yaitu meliputi :
75
76
• Broking Analisis pada Broking meliputi jumlah nilai premi, jumlah nilai objek yang diasuransikan, dan jumlah brokerage rate • Claims Analisis pada Claims meliputi jumlah claims tiap client, jumlah claims tiap resiko dan tiap kategori, jumlah deductible, dan jumlah surgery fee
4.1.3. Mengidentifikasi
dan
penyesuaian
dimensi
(Identifying
and
Conforming The Dimensions) Dalam tahap ini dilakukan identifikas i dimensi untuk setiap tabel fakta yang ada. Selain itu dalam proses indentifikasi ini diusahakan agar tabel-tabel dimensi yang ada dapat digunakan secara bersama-sama oleh beberapa tabel fakta. Berikut adalah tabel dimensi yang terdapat dalam perancangan data warehouse ini : a. Dimensi waktu b. Dimensi pelanggan c. Dimensi insurer d. Dimensi jenis resiko e. Dimensi kategori resiko f. Dimensi jenis EB Dengan rincian : I.
Untuk tabel fakta Broking, menggunakan
77
•
Dimensi waktu
•
Dimensi pelanggan
•
Dimensi insurer
•
Dimensi jenis resiko
•
Dimensi kategori resiko
Tabel 4.1 Grain vs Dimensi pada Broking
√ √ √ √
Jumlah Transaksi √ √ √ √
√
√
Nilai Premi Dimensi waktu Dimensi pelanggan Dimensi insurer Dimensi JenisResiko Dimensi Kategori resiko
II.
√ √ √ √
Nilai Objek yang diasuransikan √ √ √ √
√
√
Nilai Komisi
Untuk tabel fakta Claim, menggunakan •
Dimensi waktu
•
Dimensi pelanggan
•
Dimensi jenis resiko
•
Dimensi kategori resiko
•
Dimensi insurer
78
Tabel 4.2 Grain vs Dimensi pada Claim
Dimensi waktu Dimensi pelanggan Dimensi JenisResiko Dimensi KategoriResiko Dimensi Insurer
Jumlah Claim √ √
Jumlah Nilai Claim √ √
jumlah yang dibayarkan √ √
Jumlah Deductible √ √
√
√
√
√
√
√
√
√
√
√
√
√
III.
Untuk tabel fakta ClaimEB, menggunakan •
Dimensi waktu
•
Dimensi pelanggan
•
Dimensi jenis resiko
•
Dimensi jenis EB
•
Dimensi insurer
•
Dimensi kategori resiko
79
Tabel 4.3 Grain vs Dimensi pada Claim_EB
√
√
√
Jumlah Surgery Fee √
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Jumlah Jumlah jumlah yang Claim Nilai Claim dibayarkan Dimensi waktu Dimensi pelanggan Dimensi JenisResiko Dimensi KategoriResiko Dimensi Insurer Dimensi Jenis EB
Jumlah Deductible √
4.1.4. Memilih Fakta (Choosing The Fact) Dalam tahap ini, dipilih fakta-fakta yang akan mengisi setiap tabel fakta. Fakta-fakta yang dipilih harus sesuai dengan grain yang telah ditentukan. Fakta- fakta yang telah dipilih antara lain : 4.1.4.1 Fakta Untuk Tabel Fakta Broking Fakta yang telah ditentukan untuk tabel fakta Broking antara lain : •
Total_premi , menunjukan total premi yang dibayarkan oleh client
•
Jumlah_Transaksi , menunjukan banyaknya transaksi broking yang terjadi.
•
Total_Brokerage_rate , menunjukan nilai brokerage rate untuk setiap transaksi Broking
80
•
Total_Insured_Object , menunjukan total nilai objek yang diasuransikan.
4.1.4.2 Fakta Untuk Tabel Fakta Claim Fakta yang telah ditentukan untuk tabel fakta Claim antara lain : •
Jumlah_transaksi_Claim, menunjukan banyak transaksi claim yang terjadi.
•
Total_Nilai_Claim, menunjukan total nilai claim yang diajukan.
•
Total_deductible, M enunjukan pengurangan claim yang diajukan
4.1.4.3 Fakta Untuk Tabel Fakta ClaimEB Fakta yang telah ditentukan untuk tabel fakta ClaimEB antara lain : •
Jumlah_transaksi_Claim,menunjukan banyaknya transaksi claim yang terjadi.
•
Total_Nilai_Claim, menunjukan total nilai claim yang diajukan.
•
Total_deductible ,M enunjukan pengurangan claim yang diajukan
•
Total_surgery_fee , menunjukan total biaya operasi
tertanggung
mengajukan claim.
bagi
client
yang
81
4.1.5. Menyimpan Perhitungan Awal dalam Tabel Fakta (Storing Precalculation in The Fact Table) •
Total_premi (sum(premium))
•
Jumlah_Transaksi (count(placing_no))
•
Total_Brokerage_rate (sum(brokerage))
•
Total_Insured_Object (sum(sum_insured))
•
Jumlah_transaksi_Claim (count(claim_no))
•
Total_Nilai_Claim (sum(amount_loss))
•
Total_deductible (sum(deductible))
•
Total_surgery_fee (sum(surgeryfree))
•
Total_komisi(sum(brokerage_amt))
4.1.6. Melihat kembali tabel dimensi (Rounding Out The Dimension Tables) a. Tabel Rounding out dimension
82
Tabel 4.4 Rounding Out Dimension Dimensi Waktu
Pelanggan Insurer JenisResiko KategoriResiko JenisEB
Field Tahun Bulan Hari
Deskripsi
kode_pelanggan nama_pelanggan
Laporan dapat dilihat berdasarkan kode pelanggan dan nama pelanggan
kode_insurer nama_insurer
Laporan dapat dilihat berdasarkan kode insurer dan nama insurer
Laporan dapat dilihat tiap tahun, bulan, maupun hari
kode_jenis_resiko Laporan dapat dilihat berdasarkan kode jenis nama_jenis_resiko resiko dan nama jenis resiko kode_kategori nama_kategori kode_jenis_eb nama_jenis_eb
Laporan dapat dilihat berdasarkan kode kategori dan nama kategori Laporan dapat dilihat berdasarkan kode jenis eb dan nama jenis eb
b. Tabel-tabel dimensi •
Atribut IDPelanggan kode_pelanggan nama_pelanggan
Dimensi Pelanggan
Tabel 4.5 DimensiPelanggan Tipe Data Panjang Integer Character Varchar
4 20 50
• Dimensi Insurer
Atribut Tipe Data IDInsurer Integer kode_insurer Character nama_insurer Varchar •
Tabel 4.6 DimensiInsurer Panjang
Dimensi JenisResiko
4 20 50
83
Tabel 4.7 DimensiJenisResiko Atribut Tipe Data Panjang IDJenisResiko Integer kode_jenis_resiko Character nama_jenis_resiko Varchar •
4 8 50
Dimensi KategoriResiko
Tabel 4.8 DimensiKategoriResiko Atribut Tipe Data Panjang IDKategoriResiko Integer kode_kategori Character nama_kategori Varchar •
4 8 50
DimensiJenisEB
Tabel 4.9 DimensiJenisEB Atribut Tipe Data Panjang IDJenisEB Integer kode_jenis_eb Character nama_jenis_eb Varchar •
4 8 50
Dimensi Waktu
Atribut Tipe Data IDWaktu Integer Tahun Integer Bulan Integer Hari Integer
Tabel 4.10 DimensiWaktu Panjang 4 4 4 4
c. Perancangan S kema Bintang Dalam perancangan ini dihasilkan tiga bentuk skema bintang, yaitu : i. Skema bintang Broking ii. Skema bintang Claim
84
iii. Skema bintang ClaimEB Berikut gambar rancangan skema bintang yang dihasilkan :
Gambar 4.1 Skema Bintang Broking Skema bintang Broking pada gambar 4.1 menunjukkan total premi, jumlah transaksi, total brokerage rate, dan total insured object pada transaksi yang terjadi didalam proses broking. Skema berdasarkan pada lima dimensi yaitu DimensiJenisResiko,
DimensiInsurer,
DimensiPelanggan,
DimensiKategoriResiko, dan DimensiWaktu.
85
Gambar 4.2 Skema Bintang Claim Skema bintang Claim pada gambar 4.2 menunjukkan jumlah transaksi, total nilai ganti rugi (claim), dan total deductible pada transaksi yang terjadi didalam proses claims. Skema
berdasarkan
DimensiJenisResiko,
pada
lima
dimensi
DimensiPelanggan,
DimensiKategoriResiko, dan DimensiWaktu.
yaitu
DimensiInsurer,
86
Gambar 4.3 Skema Bintang ClaimsEB Skema
bintang
ClaimsEB
pada
gambar
4.3
menunjukkan jumlah transaksi, total nilai ganti rugi (claim), dan total deductible pada transaksi yang terjadi didalam proses claims yang berasal dari bidang medis serta total nilai biaya surgery fee. Skema berdasarkan pada enam dimensi yaitu DimensiJenisResiko, DimensiPelanggan, DimensiKategoriResiko, DimensiJenisEB, DimensiInsurer dan DimensiWaktu. Perancangan data warehouse ini menggunakan skema bintang yang memungkinkan proses query yang lebih cepat.
87
Skema bintang memiliki satu tabel fakta yang terhubung dengan tabel dimensi dengan relasi one to many. Skema bintang telah mengalami proses denormalisasi yang berasal dari database operasional, sehingga tabel transaksi diakses melalui tabel fakta yang telah mengalami penyesuaian data. 4.1.7. Memilih Durasi Database (Choosing The Duration of Database) Pada proses ini yang dilakukan adalah menentukan pembatasan waktu untuk data yang diambil dan dipindahkan ke dalam tabel fakta. Penentuan durasi dari database ini tergantung terhadap kebutuhan informasi perusahaan.
Pada data warehouse ini, durasi dari database
kami tetapkan selama 5 tahun. Hal ini dikarenakan kebutuhan informasi dari PT. Indosurance Broker Utama memerlukan informasi dalam rentang waktu 5 tahun. Tabel 4.11 Durasi database dan data warehouse
Nama Aplikasi
Database
Database ada sejak tahun
Data yang masuk ke dalam Data warehouse
Data dalam data warehous e
Insurance
SQL Server 2005
2004
5 tahun
5 tahun
88
4.1.8. Menelusuri Perubahan dari Dimensi secara Perlahan (Tracking Slowly Changing Dimension) Pada proses ini yang dilakukan adalah mengamati perubahan data dari dimensi pada tabel dimensi. Dalam menangani slowly changing dimension, kami memilih untuk membuat record baru pada tabel dimensi tersebut. Dengan demikian maka data-data dimensi yang lama bisa disimpan secara utuh dan tidak hilang begitu saja dari data warehouse. Namun,
terdapat
kekurangan
yaitu
pemakaian
kapasitas
media
penyimpanan untuk tabel dimensi akan membesar karena perubahan pada sebagian atribut akan menyebabkan munculnya record baru. Proses dalam slowly changing dimension adalah sebagai berikut : Nama Tabel : Dimensi Kategori Resiko Deskripsi Tabel : Tabel Dimensi Kategori Resiko Surrogate Key : IDKategoriResiko Application Key : kode_kategori Tabel 4.12 Contoh data pada Dimensi Kategori Resiko IDKategoriResiko kode_kategori nama_kategori 1 C CASUALITY 2 S SERVICE Ketika suatu saat nama kategori resiko berubah, maka data lama dan data baru akan tetap disimpan. Sehingga tabel Dimensi kategori resiko akan berubah menjadi :
89
Tabel 4.13 Contoh data pada Dimensi Kategori Resiko setelah mengalami perubahan IDKategori Resiko kode_kategori nama_kategori 1 C CASUALITY 2 S SERVICE ADM INISTRATION SERVICE ONLY 3 S (ASO) PROGRAM Nama Tabel : Dimensi Jenis Resiko Deskripsi Tabel : Tabel Dimensi Jenis Resiko Surrogate Key : IDJenisResiko Application Key : kode_jenis_resiko Tabel 4.14 Contoh data pada Dimensi Jenis Resiko IDJenisResiko kode_jenis_resiko nama_jenis_resiko 1 EXP Expedition 2 HOSP Hospital And Surgical Ketika suatu saat nama jenis kategori resiko berubah, maka data lama dan data baru akan tetap disimpan. Sehingga tabel Dimensi jenis resiko akan berubah menjadi : Tabel 4.15 Contoh data pada Dimensi Jenis Resiko setelah mengalami perubahan IDJenisResiko kode_ jenis_resiko nama_jenis_resiko 1 EXP Expedition 2 HOSP Hospital And Surgical 3 EXP M arine Cargo Open Cover
90
4.1.9. Memutuskan Prioritas Query dan Tipe Query (Deciding The Query Priorities and The Query Modes) Pada langkah ini, difokuskan pada persoalan perancangan fisik (physical design) untuk data warehouse. Persoalan perancangan fisik data warehouse yang paling kritis dan yang mempengaruhi pandangan pengguna akhir terhadap data warehouse adalah urutan fisik dari tabel fakta pada tempat penyimpanan (disk) dan pengadaan ringkasan yang disimpan sebelumnya atau penggabungan atara keduanya. Di luar persoalan-persoalan tersebut ada sejumlah persoalan perancangan fisik tambahan yang mempengaruhi administrasi, backup, kinerja pengurutan (indexing), dan keamanan dalam pengaksesan maupun penyimpanan data dan analisis kapasitas media penyimpanan. Untuk dapat menghasilkan perancangan data warehouse yang baik sehingga dapat digunakan sebagai laporan kepada pihak eksekutif, maka harus menyelesaikan persoalan yang mempengaruhi segi administrasi, backup, kinerja pengurutan (indexing) , dan keamanan dalam pengaksesan maupun penyimpanan data dan analisis kapasitas media penyimpanan. Berikut ini adalah hal-hal yang penting untuk dapat menghasilkan laporan yang baik kepada pihak eksekutif : 1. Administrasi Pada proses administrasi ini biasanya akan dilakukan proses ETL (Extract, Transform, Loading). Yang melakukan proses ini biasanya adalah IT Supervisor, agar jika terjadi permasalahan pada proses ETL ini,
91
dapat diperbaiki dengan segera. Dan biasanya proses ETL ini dilakukan setiap hari. 2. Back-up Proses backup merupakan proses yang sangat penting dalam proses ETL. Proses backup ini bertujuan untuk membuat salinan data yang dapat digunakan untuk memperbaiki suatu data apabila suatu saat terjadi kerusakan data pada data warehouse. Proses ini berlangsung setelah proses ETL dilakukan, dan hasil proses backup ini disimpan dalam media penyimpanan (disk). Terkadang dalam proses penyimpanan hasil backup ini terjadi masalah, karena data backup ini akan menggunakan tempat penyimpanan (disk) yang cukup besar. M aka biasanya setiap 1 tahun sekali data backup tersebut akan dipindahkan kedalam DVD atau magnetic tape. 3. Recovery Recovery merupakan proses memperbaiki atau mengembalikan data kepada kondisi yang telah disimpan sebelumnya ketika terjadi kerusakan data. Proses recovery ini harus dilakukan oleh bagian IT atau bagian yang mengerti akan proses ini, karena sebelum proses ini dilakukan haruslah memeriksa data manakah yang mengalami kerusakan sehingga dapat mengetahui data backup yang sesuai untuk proses recovery ini. 4. Security
92
Tingkat
keamanan
dalam
pengaksesan
data
perusahaan
memegang peranan yang sangat penting. Hal ini betujuan agar pengaksesan maupun perubahan data perusahaan tidak dilakukan oleh pihak yang tidak berkepentingan. Security pada hal ini dibagi menjadi 2, yaitu authentication dan authorization. Authentication adalah pembatasan user yang berwenang untuk mengakses data yang ada di dalam suatu perusahaan sedangkan authorization adalah pembatasan hak akses terhadap masing-masing user untuk dapat melihat ataupun merubah data yang ada dari suatu perusahaan. 5. Analisis Kapasitas M edia Penyimpanan Dalam perancangan data warehouse, perlu dilakukan analisis kapasitas media penyimpanan data untuk dapat mendapatkan perkiraan kapasitas media penyimpanan yang memadai untuk dapat menampung data dalam beberapa tahun ke depan. •
M engitung Kapasitas Disk 1. M enentukan perkiraan jumlah baris (record) di dalam tabel. 2. M enentukan ukuran data, tergantung pada tipe data dan panjangnya. Tipe data dan ukurannya dalam byte yang dipakai dalam data
warehouse ini adalah :
93
•
Varchar(n),
ukurannya berbeda-beda tergantung pada jumlah
character yang digunakan, dan character maksimum yang digunakan adalah sebesar n byte. •
Integer, mempunyai ukuran statis yaitu sebesar 4 byte Berikut adalah perkiraan kapasitas yang dibutuhkan oleh masing-
masing tabel dimensi dan tabel fakta dalam jangka 5 tahun ke depan. Analisis Untuk Tabel Dimensi Insurer Besar ukuran maksimal dalam satu record pada dimensi insurer adalah = integer + character(20) + varchar(50) = 4 + 20 + 50 = 74 byte. Asumsi untuk jumlah record per tahun adalah 400 record pelanggan,baik yang masih aktif maupun tidak, Jumlah tersebut berdasar pada asumsi rata-rata tiap tahun terjadi 10 pertambahan insurer, 10 record tersebut dapat merupakan pertambahan insurer baru maupun perubahan dari insurer yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total untuk 5 tahun ke depan adalah sebesar = 500 + 10 x 5 = 550 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi insurer 5 tahun ke depan adalah =550 x 74 byte = 40700 bytes = 35,75 Kbytes
94
Analisis Untuk Tabel Dimensi Resiko Besar ukuran maksimal dalam satu record pada dimensi Resiko adalah = integer + character(8) + varchar(50) = 4 + 8 + 50 = 62 byte. Asumsi untuk jumlah record per tahun adalah 20 record ,baik yang masih aktif maupun tidak, dan perkiraan pertambahan jumlah resiko untuk 1 tahun ke depan sebesar 3 record, 3 record tersebut dapat merupakan pertambahan resiko baru maupun perubahan dari resiko yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total pada dimensi resiko untuk 5 tahun ke depan adalah sebesar = 20 + 3 x 5 = 35 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi insurer 5 tahun ke depan adalah =35 x 62 byte = 1984 bytes = 1.9375 Kbyte Analisis Untuk Tabel Dimensi Pelanggan Besar ukuran maksimal dalam satu record pada dimensi pelanggan adalah = integer + character(20) + varchar(50) = 4 + 20 + 50 = 74 byte. Dengan asumsi untuk jumlah record per tahun adalah 4.000, baik yang masih aktif maupun tidak, dan perkiraan pertambahan jumlah pelanggan untuk 1 tahun ke depan sebesar 300 record, record tersebut dapat merupakan pertambahan pelanggan baru maupun perubahan dari
95
pelanggan yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total untuk 5 tahun ke depan adalah sebesar = 4000 + 300 x 5 = 5500 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi pelanggan 5 tahun ke depan adalah = 5500 x 74 byte = 407000 bytes = 397,461 Kbyte Analisis Untuk Tabel Dimensi Waktu Besar ukuran maksimal dalam satu record pada dimensi waktu adalah = integer + integer + integer + integer = 4 + 4 + 4 + 4 = 16 byte. Perkiraan pertambahan jumlah pelanggan untuk 1 tahun ke depan sebesar 365 record. M aka perkiraan jumlah record total untuk 5 tahun ke depan adalah sebesar = 365 x 5 = 1825 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi waktu 5 tahun ke depan adalah = 1825 x 16 byte = 29200 bytes = 28,5156 Kbyte Analisis Untuk Tabel Dimensi Kategori Resiko Besar ukuran maksimal dalam satu record pada dimensi Kategori Resiko adalah = integer + character(8) + varchar(50) = 4 + 8 + 50 = 62 byte.
96
Dengan asumsi untuk jumlah record per tahun adalah 20, baik yang masih aktif maupun tidak, dan perkiraan pertambahan jumlah kategori untuk 1 tahun ke depan sebesar 2 record, record tersebut dapat merupakan pertambahan kode baru maupun perubahan dari kode yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total untuk 5 tahun ke depan adalah sebesar = 20 + 2 x 5 = 30 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi pelanggan 5 tahun ke depan adalah = 30 x 62 byte = 1860 bytes = 1,8 Kbyte Analisis Untuk Tabel Dimensi Jenis EB Besar ukuran maksimal dalam satu record pada dimensi JenisEB adalah = integer + character(8) + varchar(50) = 4 + 8 + 50 = 62 byte. Dengan asumsi record untuk tahun pertama adalah 120 record. Jumlah tersebut berdasarkan pada asumsi rata-rata tiap bulan terjadi penambahan 2 record. M aka perkiraan jumlah record total untuk 5 tahun ke depan adalah sebesar = 120 + 2 x 12 x 5 = 240 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data dimensi pelanggan 5 tahun ke depan adalah = 240 x 62 byte = 14880 bytes
97
= 14,5 Kbyte 1. Fakta Broking Asumsi untuk jumlah record tahun ini adalah 15.000 record. Jumlah tersebut berdasar pada asumsi rata-rata tiap bulan terjadi 1250 transaksi. Asumsi untuk jumlah record tahun ini adalah 15.000 record. Jumlah tersebut berdasar pada asumsi rata-rata tiap bulan terjadi 1250 transaksi. Besar ukuran maksimal dalam satu record pada dimensi insurer adalah = integer + integer + integer + integer + integer + money + integer + money + money = 4 + 4 + 4 + 4 + 4 + 8 + 4 + 8 + 8 = 48 byte. Dengan asumsi untuk jumlah record per tahun adalah 15.000 ,baik yang masih aktif maupun tidak, dan perkiraan pertambahan jumlah record diasumsikan rata-rata tiap bulan terjadi 1250 transaksi, record tersebut dapat merupakan pertambahan transaksi broking baru maupun perubahan dari broking yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total pada dimensi resiko untuk 5 tahun ke depan adalah sebesar = 15.000 + 1250 x 12 x 5 = 90.000 record Jadi perkiraan
kapasitas media penyimpanan yang
diperlukan untuk menyimpan data fakta broking 5 tahun ke depan adalah = 90.000 x 48 byte
98
= 4.320.000 bytes = 4.218,75 Kbyte 2. Fakta Claim Besar ukuran maksimal dalam satu record pada tabel fakta Claim adalah = integer + integer +integer +integer + integer +integer + money + money = 6 x 4 + 8 + 8 = 40 byte Asumsi untuk jumlah record per tahun adalah 7200 record claim, Jumlah tersebut berdasar pada asumsi rata-rata tiap bulan terjadi 600 transaksi, 600 record tersebut dapat merupakan pertambahan claim baru maupun perubahan dari claim yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total pada fakta claim untuk 5 tahun ke depan adalah sebesar = 7200 + 600 x 12 x 5 = 43.200 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data fakta claim 5 tahun ke depan adalah =43.200 x 40 byte = 1.728.000 bytes = 1687.5 Kbyte
3. Fakta ClaimEB Besar ukuran maksimal dalam satu record pada fakta claimEB adalah = integer (4) + integer (4) + integer (4) + integer
99
(4) + integer (4) + integer (4) + integer (4) + money (8) + money (8) = 4 x 7 + 16 = 44 byte. Asumsi untuk jumlah record pertahun
adalah 9000
record. Jumlah tersebut berdasar pada asumsi rata-rata tiap bulan terjadi 3000 transaksi. 3000 record tersebut dapat merupakan pertambahan claimEB baru maupun perubahan dari claimEB yang telah ada sebelumnya dalam data warehouse. M aka perkiraan jumlah record total pada fakta claimEB untuk 5 tahun ke depan adalah sebesar: 9000 + 3000 x 12 x 5= 189.000 record Jadi perkiraan kapasitas media penyimpanan yang diperlukan untuk menyimpan data fakta claim 5 tahun ke depan adalah = 189.000 x 44 byte = 8.316.000 bytes = 8.121,093 Kbyte Berdasarkan hasil perhitungan estimasi yang telah dilakukan, dapat ditentukan bahwa total ukuran kapasitas media penyimpanan untuk jangka waktu lima tahun adalah 14.524Kbyte, yang terdiri dari total transaksi pertahun yang mencapai 58.882 record serta 330.380 record selama jangka waktu lima tahun.
100
Tabel 4.16 Tabel Analisa Kapasitas M edia Penyimpanan
Estimasi Besar 1 banyak record Record transaksi (byte) awal pertahun 40 7200 7200 48 15000 15000 44 9000 36000 74 400 10 62 20 3 74 4000 300 16 0 365
Nama Tabel Fakta Claim Fakta Broking Fakta ClaimEB Dimensi Insurer Dimensi Resiko Dimensi Client Dimensi Waktu Dimensi Kategori Resiko 62 Dimensi Jenis EB 62 Jumlah
Estimasi banyak transaksi perlima tahun 43200 90000 180000 550 35 5500 1825
Size(Kbyte) 1688 4219 8121 40 2 398 29
20
2
30
2
120
2 58882
240 330380
15 14524
4.1.10. Metadata Informasi mengenai struktur dari data yang terdapat pada data warehouse terdapat di dalam
metadata, yaitu informasi tentang data yang
digunakan. Apakah itu dalam hasil transformasi data yang dilakukan ataupun data yang diciptakan guna keperluan dalam membangun data warehouse. Berikut ini adalah metadata dari data yang digunakan dalam rancangan data warehouse
101
102
103
104
105
106
107
108
109
110
4.2.
Arsitektur Data Warehouse
Gambar 4.4 Arsitektur Data Warehouse Dalam perancangan data warehouse tahap pertama yang dilakukan adalah pemilihan data yang diperlukan untuk pembuatan laporan bagi pihak eksekutif. Pemilihan data ini dilakukan karena tidak semua data yang ada pada OLTP diperlukan di dalam data warehouse. Setelah pemilihan data selesai dilakukan, data-data tersebut diambil dan dipindahkan ke dalam media penyimpanan data yang besar.Dalam proses perpindahan ini akan dilakukan proses transformasi data agar data yang dipindahkan tersebut berada dalam bentuk yang terintegrasi dan konsisten. Arsitektur data warehouse yang akan dibangun untuk perusahaan ini adalah menggunakan anatomi data warehouse terpusat. Alasan menggunakan anatomi data warehouse terpusat antara lain sebagai berikut : • Arsitektur data warehouse terpusat sudah umum digunakan oleh banyak perusahaan.
111
•
Pengembangan
arsitektur yang relatif
lebih mudah dan murah
dibandingkan dengan arsitektur data warehouse terdistribusi. •
Lebih mudah dilakukan pemeliharaan dan pengawasan data karena data hanya ditempatkan pada 1 tempat saja.
Sistem data warehouse ini terdiri dari komponen-komponen sebagai berikut : 1. Sumber data Sumber data berasal dari database operasional yang dimiliki PT. Indosurance Broker Utama dengan nama database IBU. Data operasional yang diambil berasal dari tabel : •
m_client : Tabel yang berisi daftar pelanggan dari perusahaan
•
m_insurer: Tabel yang berisi daftar partner asuransi dari perusahaan
•
m_policy: Tabel yang berisi polis asuransi
•
t_adjuster: Tabel yang berisi daftar pihak ketiga yang umumnya kalangan professional
•
t_category : Tabel yang berisi jenis resiko
•
t_claim_eb : Tabel yang berisi jenis-jenis klaim yang berasal dari bidang medis
•
t_code : Tabel yang berisi jenis polis asuransi secara khusus
•
t_currency : Tabel yang berisi daftar mata uang
•
t_risk : Tabel yang berisi daftar resiko secara umum
•
tr_claim : Tabel transaksi untuk proses pengajuan ganti rugi
•
tr_claim_eb : Tabel transaksi untuk proses pengajuan ganti rugi yang berasal dari bidang medis
112
•
tr_claim_ebd : yang berasal dari bidang medis yang berisi rincian nilai kehilangan yang dialami oleh pelanggan
•
tr_placingh : Tabel transaki yang berisi daftar polis asuransi yang sudah disetujui oleh pelanggan dan partner asuransi
•
tr_proposalh : Tabel transaki yang berisi daftar polis asuransi yang diajukan ke pelanggan
•
tr_quotationh : Tabel transaki yang berisi daftar polis asuransi yang diajukan ke partner asuransi
2. Transformasi data Data yang berasal dari sumber data dapat mempunyai format atau tipe data yang berbeda. M aka untuk mengubah karakteristik data atau tipe data yang masuk ke dalam data warehouse agar data sudah konsisten dan terintegrasi perlu dilakukan proses ekstrak dan transformasi. Sumber data untuk data warehouse berasal dari database transaksional dengan menggunakan format SQL Server 2005 kemudian dikonversikan ke dalam data warehouse yang juga menggunakan format SQL Server 2005. Untuk melakukan proses transformasi ini digunakan fasilitas DTS yang telah dimiliki oleh SQL Server 2005. 3. Data Warehouse Data yang telah selesai dilakukan proses transformasi dan saling terintegrasi akan dijadikan sumber data untuk pembuatan laporan yang ditujukan bagi pihak eksekutif. Data yang terkumpul di dalam data warehouse merupakan data yang bersifat historis dan summaries dengan jangka waktu tertentu. Data yang ada di dalam data warehouse ini menggunakan format SQL Server 2005.
113
4. Cube Cube merupakan bentuk data multi-dimensional, yang terbentuk dari tabel fakta dan tabel dimensi. Tabel fakta dan tabel dimensi untuk cube dirancang melalui the nine steps methodology. 5. Front end tools Komponen ini ditujukan kepada user untuk memudahkan dalam pengaksesan data yang akan digunakan untuk pembuatan laporan bagi eksekutif. Front end tools yang digunakan dalam data warehouse ini adalah Visual Basic .Net dan Xcelcius, dimana VB.Net bertindak sebagai front end tool yang mengubungkan user dengan data warehouse yang dirancang.
4.3.
Transformasi Data Transformasi data adalah proses yang penting untuk dilakukan guna memindahkan data yang berasal dari sumber data kedalam tempat penyimpanan baru nanti yang akan digunakan sebagai sumber data warehouse. Seluruh datadata yang berada di dalam data warehouse harus konsisten, sebab didalam data warehouse tidak ada operasi delete ataupun update. Proses transformasi ini menggunakan DTS (Data Transformation Services) yang merupakan salah satu fasilitas yang terdapat didalam SQL 2005 yang dapat melakukan import dan export data dari berbagai sumber yang sama dengan mengunakan wizard yang dapat memudahkan dalam melakukan proses transformasi.
114
Langkah-langkah
transformasi
yang
akan
dilakukan
pada
PT.
INDOSURANCE BROKER UTAM A adalah sebagai berikut: •
M embaca dan memilih data-data operasional yang berhubungan dengan informasi yang diminta. Dan kemudian dilakukan penyaringan data-data yang akan digunakan dan yang tidak akan digunakan, lalu ditampung ke dalam tempat penyimpanan sementara.
•
M elakukan penyeragaman data dan jika memang diperlukan dapat dilakukan perubahan format data sebelum dimasukan kedalam data warehouse.
•
Data-data
yang
telah
terpilih
tersebut
kemudian
di
transformasikan dari tempat penyimpanan sementara ke dalam data warehouse.
115
Proses Transformasi tabel DimensiPelanggan
Gambar 4.5 Transformasi pada DimensiPelanggan Gambar 4.5 memperlihatkan transformasi data dari tabel m_client (source) menuju tabel DimensiPelanggan (destination), yaitu berupa client_code dan client_name. Tabel m_client terdapat pada database operasional sedangkan tabel DimensiPelanggan adalah tabel yang terdapat pada database data warehouse yang digunakan sebagai tabel dimensi. Proses transformasi tersebut
116
diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination. Proses Transformasi Tabel DimensiInsurer
Gambar 4.6 Transformasi pada DimensiInsurer Gambar 4.6 memperlihatkan transformasi data dari tabel m_insurer (source) menuju tabel DimensiInsurer (destination), yaitu berupa insurer_code
117
dan insurer_name. Tabel m_insurer terdapat pada database operasional sedangkan tabel DimensiInsurer adalah tabel yang terdapat pada database data warehouse yang digunakan sebagai tabel dimensi. Proses transformasi tersebut diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
118
Proses Transformasi Tabel DimensiJenisResiko
Gambar 4.7 Transformasi pada DimensiJenisResiko Gambar 4.7 memperlihatkan transformasi data dari tabel t_code (source) menuju tabel DimensiJenisResiko (destination), yaitu berupa format_code dan format_name. Tabel t_code terdapat pada database operasional sedangkan tabel
119
DimensiJenisResiko adalah tabel yang terdapat pada database data warehouse yang digunakan
sebagai tabel dimensi. Proses
transformasi tersebut
diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination. Proses Transformasi Tabel DimensiKategoriResiko
Gambar 4.8 Transformasi pada DimensiKategoriResiko
120
Gambar 4.8 memperlihatkan transformasi data dari tabel t_category (source) menuju tabel DimensiKategoriResiko (destination), yaitu berupa category_code dan category_name. Tabel t_category terdapat pada database operasional sedangkan tabel DimensiKategoriResiko adalah tabel yang terdapat pada database data warehouse yang digunakan sebagai tabel dimensi. Proses transformasi
tersebut
diperlihatkan
oleh
gambar
menghubungkan kedua kolom source dan destination.
arah
panah
yang
121
Proses Transformasi Tabel DimensiJenisEB
Gambar 4.9 Transformasi pada DimensiJenisEB Gambar 4.9 memperlihatkan transformasi data dari tabel t_claim_eb (source) menuju tabel DimensiJenisEB (destination), yaitu berupa claim_code dan claim_desc. Tabel t_claim_eb terdapat pada database operasional sedangkan
122
tabel DimensiJenisEB adalah tabel yang terdapat pada database data warehouse yang digunakan
sebagai tabel dimensi. Proses
transformasi tersebut
diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
123
Proses Transformasi Tabel DimensiWaktu
Gambar 4.10 Transformasi pada DimensiWaktu
Gambar 4.10 memperlihatkan transformasi data dari tabel waktu pada database operational ke tabel DimensiWaktu yang ada pada database data
124
warehouse. Untuk proses transformasi ini, data-data yang dibutuhkan oleh DimensiWaktu (destination) dapat diperoleh melalui tabel waktu yang isinya terdiri dari join waktu penginputan data dari tabel-tabel yang terdapat pada database operasional yang di tunjukan pada kolom source pada gambar di atas. Proses transformasi tersebut diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
125
Proses Transformasi Tabel FaktaBroking
Gambar 4.11 Transformasi pada FaktaBroking Gambar DimensiWaktu,
4.11
memperlihatkan
DimensiPelanggan,
transformasi
DimensiInsurer,
data
dari
tabel
DimensiJenisResiko,
126
DimensiKategoriResiko (source) ke tabel FaktaBroking (destination). Baik tabel DimensiWaktu,
DimensiPelanggan,
DimensiInsurer,
DimensiJenisResiko,
DimensiKategoriResiko maupun tabel FaktaBroking, seluruhnya terdapat pada database yang sama. Pada proses transformasi tersebut, data yang diperlukan oleh tabel FaktaBroking (destination) akan diambil dari hasil penggabungan atau join antara data-data yang terdapat pada DimensiWaktu, DimensiPelanggan, DimensiInsurer,
DimensiJenisResiko,
DimensiKategoriResiko
yang
berhubungan dengan FaktaBroking. Proses transformasi tersebut diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
127
Proses Transformasi Tabel FaktaClaim
Gambar 4.12 Transformasi pada FaktaClaim Gambar DimensiWaktu,
4.12
memperlihatkan
DimensiPelanggan,
transformasi
DimensiInsurer,
data
dari
tabel
DimensiJenisResiko,
DimensiKategoriResiko (source) ke tabel FaktaClaim (destination). Baik tabel
128
DimensiWaktu,
DimensiPelanggan,
DimensiInsurer,
DimensiJenisResiko,
DimensiKategoriResiko maupun tabel FaktaClaim, seluruhnya terdapat pada database yang sama. Pada proses transformasi tersebut, data yang diperlukan oleh tabel FaktaClaim (destination) akan diambil dari hasil penggabungan atau join antara data-data yang terdapat pada DimensiWaktu, DimensiPelanggan, DimensiInsurer,
DimensiJenisResiko,
DimensiKategoriResiko
yang
berhubungan dengan FaktaClaim. Proses transformasi tersebut diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
129
Proses Transformasi Tabel FaktaClaimEB
Gambar 4.13 Transformasi pada FaktaClaimEB
130
Gambar DimensiWaktu,
4.13
memperlihatkan
DimensiPelanggan,
transformasi
data
DimensiInsurer,
dari
tabel
DimensiJenisEB,
DimensiJenisResiko, DimensiKategoriResiko (source) ke tabel FaktaClaimEB (destination). Baik tabel DimensiWaktu, DimensiPelanggan, DimensiInsurer, DimensiJenisEB, DimensiJenisResiko, DimensiKategoriResiko maupun tabel FaktaClaimEB, seluruhnya terdapat pada database yang sama. Pada proses transformasi tersebut, data yang diperlukan
oleh
tabel FaktaClaimEB
(destination) akan diambil dari hasil penggabungan atau join antara data-data yang terdapat pada DimensiWaktu, DimensiJenisEB,
DimensiJenisResiko,
DimensiPelanggan,
DimensiInsurer,
DimensiKategoriResiko
yang
berhubungan dengan FaktaClaimEB. Proses transformasi tersebut diperlihatkan oleh gambar arah panah yang menghubungkan kedua kolom source dan destination.
4.4.
OLAP Setelah data warehouse terbentuk, maka selanjutnya cube dirancang sesuai dengan kebutuhan manajerial dengan menggunakan M icrosoft Analysis Services yang disediakan oleh SQL Server 2005. Cube yang terbentuk adalah :
131
Gambar 4.14 Hubungan antara FaktaClaim dengan dimensi-dimensinya
Gambar 4.15 Contoh data-data pada CUBE_CLAIM
132
Gambar 4.16 Hubungan antara FaktaBroking dengan dimensi-dimensinya
Gambar 4.17 Contoh data-data pada CUBE_BROKING
133
Gambar 4.18 Hubungan antara FaktaClaimEB dengan dimensi-dimensinya
Gambar 4.19 Contoh data-data pada CUBE_CLAIM _EB
134
4.5.
Kebutuhan Hardware dan Software 4.5.1. Kebutuhan Hardware Hardware pada bagian ini memiliki arti sebagai komponen yang secara fisik digunakan untuk mendukung implementasi data warehouse yang dibangun. Hardware yang digunakan dalam mengimplementasikan data warehouse pada PT. Indosurance Broker Utama menggunakan sebuah server. Penggunaan server ini karena mempertimbangkan faktor performance dari query dalam menyajikan report data warehouse. Pertimbangan lainnya dalam hal menggunakan server adalah faktor keamanan data dari gangguan-gangguan yang tidak diinginkan. Untuk mendapatkan performa yang optimal dalam menjalankan aplikasi data warehouse maka diperlukan konfigurasi perangkat keras (hardware) sebagai berikut : Tabel 4.26 Spesifikasi hardware Keterangan
Server
Client
• • • • • • • • • •
S pesifikasi HP Proliant DL 380 GS, Intel Xeon ® CPU 1,86 GHz, 2 GB RAM , HardDisk 200 GB Direct 9.0c Processor Intel Pentium 4 1,6Ghz DDR 640M B HDD 80GB M ainboard ECS M onitor 17”
135
4.5.2. Kebutuhan Software Perangkat lunak (software) yang digunakan sebagai front end tool yang menghubungkan antara pengguna dengan data warehouse yang dirancang adalah M icrosoft Visual Studio .Net. Untuk menampilkan representasi data dari data warehouse yang ada, baik berupa angka-angka maupun grafik, digunakan tool lainnya yaitu Crystal Excelsius 2008 XI Business Objects. Sedangkan
perangkat
lunak
yang
digunakan
untuk
mendukung proses pengumpulan sumber data dan menyimpan datadata tersebut adalah SQL Server 2005. Untuk menjalankan proses ETL (extract,transform,loading) dibutuhkan suatu tool tambahan yaitu M icrosoft Visual Studio 2005 SQL Server Integration Services yang telah disediakan oleh SQL Server 2005. Sedangkan tool yang digunakan untuk pembuatan cube dari data warehouse sehingga datadatanya mudah untuk di analisis adalah menggunakan M icrosoft Visual Studio 2005 SQL Server Analysis Services. Berikut adalah beberapa perangkat lunak dan sistem operasi yang dapat digunakan dalam menjalankan aplikasi data warehouse PT. Indosurance Broker Utama :
136
Tabel 4.27 Spesifikasi software Keterangan
Sistem Operasi dan RDBMS • Windows Server 2003 R2 (5.2, Build 3790) • M icrosoft SQL Server 2005 • M icrosoft Visual Studio 2005 • Windows XP Professional SP 2 • M icrosoft Visual Studio 2005 • M icrosoft Office Excel 2007 • Adobe Flash Player 9 • Adobe Acrobat Reader 9.0
Server
Client
4.6.
Rencana Implementasi Tabel 4.28 Rencana implementasi
aktifitas Instalasi Software dan Hardware Uji coba aplikasi Pelatihan user Evaluasi
1 x
2
minggu 3
4
5
x
x
x x
Keterangan : 1. Instalasi Software dan Hardware Pada tahapan ini mulai dilakukan pemasangan hardware serta penginstalan software pada computer-komputer klien, Tahapan ini dilakukan selama satu minggu. 2. Uji coba aplikasi Adalah tahapan uji coba terhadap perancangan aplikasi data warehouse di bagian IT. Tahapan ini dilakukan selama satu minggu.
137
3. Pelatihan user Yang dilakukan pada tahapan ini ialah memberikan pelatihan kepada user pada saat uji coba aplikasi, sehingga authorized user dapat menggunakan aplikasi dengan baik dan lancar. Kegiatan pelatihan ini dilakukan selama satu minggu. 4. Evaluasi Pada tahapan terakhir dari rencana implementasi data warehouse ini akan dilakukan evaluasi guna melihat apakah sistem yang diimplementasikan sudah memenuhi kriteria kebutuhan user, serta menemukan kelemahan dari hasil implementasi yang sudah dilakukan.
4.7.
Rencana Backup, Recovery, dan Security 4.7.1. Backup Proses
backup data
warehouse perlu
dilakukan
oleh
perusahaan guna menghindari kerusakan atau kehilangan data yang di sebabkan oleh kerusakan pada server, pencurian, bencana alam dan lain-lain. Proses backup pada data warehouse akan dilakukan setiap satu bulan sekali. Untuk proses backup terhadap database data warehouse akan dilakukan secara complete untuk proses backup pertama kali, dimana akan dilakukan backup secara keseluruhan. Kemudian untuk selanjutnya akan dilakukan dengan
metode
differential dimana backup dilakukan terhadap data yang mengalami
138
perubahan saja. Data dari hasil backup akan disimpan melalui media disc dan harddisk. 4.7.2. Recovery Proses ini dilakukan untuk mengambil kembali data yang telah terhapus, rusak ataupun hilang dengan melakukan restore pada data yang telah di backup sebelumnya. Untuk proses
restore dapat dilakukan
sesuai dengan
kebutuhan, dengan metode complete atau differential. Jika restore data diinginkan secara keseluruhan maka dapat dilakukan dengan metode complete. Sedangkan jika hanya ingin sebagian saja dapat dilakukan dengan metode differential. Proses restore tidak memiliki jadwal tertentu dan hanya dilakukan jika dibutuhkan oleh user. 4.7.3. Security Untuk security terdapat dua macam proses, yaitu : 1. Authentication M asalah keamanaan pada data yang terdapat pada database data warehouse maupun cube yang terdapat di OLAP dapat diatasi dengan memberikan account berupa username dan password sehingga hanya user-user terdaftar saja yang dapat mengakses data yang ada. 2. Authorization Authorization sangat dibutuhkan guna membatasi hak akses dari pengguna yang dapat mengakses data yang terdapat
139
pada OLAP. Setiap user dapat mengakses cube dan grafik sesuai dengan yang telah di tentukan oleh database administrator.
4.8.
Rancangan Layar •
M enu Login
Gambar 4.20 Rancang layar menu login
140
•
M enu Utama
Gambar 4.21 Rancang layar menu utama
141
•
About Us
Gambar 4.22 Rancang layar about us
142
•
M enu Report
Gambar 4.23 Rancang layar report
143
•
M enu Chart
Gambar 4.24 Rancang layar grafik
4.9.
Prosedur Penggunaan Progam Prosedur penggunaan program aplikasi laporan PT. Indosurance Broker Utama : •
Pada awal user membuka aplikasi, akan muncul Splash Screen selama 3 detik.
144
Gambar 4.25 Tampilan halaman awal
•
Setelah splash screen dijalankan selama 3 detik maka akan menuju ke halaman login.
145
Gambar 4.26 Tampilan halaman login Username dan Password harus diisi. Jika tidak diisi maka akan mucul pesan kesalahan :
Gambar 4.27 Tampilan Pesan kesalahan login jika kosong Jika user memasukan username dan password yang tidak cocok dengan username dan password yang ada pada SQL server authentication maka akan muncul pesan kesalahan :
146
Gambar 4.28 Tampilan pesan kesalahan login mengalami kesalahan Jika user memasukan username dan password dengan benar maka form akan berubah menjadi halaman utama dan muncul kotak dialog :
Gambar 4.29 Pesan tampilan login sukses •
Setelah berhasil Login maka akan muncul halaman utama yang terdiri dari menu File, Report, Chart, About, Help. Di dalam halaman utama ini terdapat grafik-grafik yang menggambarkan persentase atau jumlah dari fakta-fakta yang ada. Data dari grafik ini berasal dari data-data yang ada pada tabel pivot dari M icrosoft Excel. Grafik-grafik ini dipisahkan dengan 3 submenu yang ada di bagian atas dashboard yaitu broking, claim dan claim EB sesuai dengan tabel fakta yang ada. Submenu broking menampilkan jumlah insured object dan brokerage rate yang dapat dilihat berdasarkan kategori resiko.
147
Gambar 4.30 Tampilan dashboard Broking Submenu claims menampilkan total deductible dan claim value yang dapat dilihat berdasarkan kategori resiko.
148
Gambar 4.31 Tampilan dashboard Claims Submenu Claims EB menampilkan total deductible dan Claim value yang dapat dilihat berdasarkan tipe EB.
149
Gambar 4.32 Tampilan dashboard Claims EB
150
Gambar 4.33 Tampilan menu utama •
Pada menu File terdapat pilihan Change Password , Logout dan exit. Jika user memilih Logout, maka halaman utama akan tertutup dan kembali ke halaman login. Jika user memilih exit maka aplikasi akan tertutup. Jika user memilih change password maka akan tampil form change password yang berfungsi untuk mengganti password user yang sedang login. Langkah-langkah
untuk
mengganti
password
yaitu
user
harus
memasukan password nya yang lama, password baru dan confirmation password yang berfungsi agar password yang dimasukan telah benar.
151
Gambar 4.34 Tampilan change password •
Pada menu report terdapat 3 submenu yaitu broking report , claim report, claim eb report. Broking report akan menampilkan pivot tabel dari Cube Broking yang telah ada pada analysis service. Isi dari pivot tabel ini dapat dipilih langsung oleh user dengan cara memilih checkbox yang sesuai dengan kebutuhan user.
152
Gambar 4.35 Tampilan report broking Claim report akan menampilkan pivot tabel dari Cube Claim yang telah ada pada analysis service. Isi dari pivot tabel ini dapat dipilih langsung oleh user dengan cara memilih checkbox yang sesuai dengan kebutuhan user.
153
Gambar 4.36 Tampilan report Claims Claim EB report akan menampilkan pivot tabel dari Cube Claim EB yang telah ada pada analysis service. Isi dari pivot tabel ini dapat dipilih langsung oleh user dengan cara memilih checkbox yang sesuai dengan kebutuhan user.
154
Gambar 4.37 Tampilan report ClaimsEB •
Pada menu Chart, terdapat 3 submenu yaitu Broking Chart , Claims Chart, Claims EB Chart. Broking Chart akan menampilkan chart yang menunjukan total measure yang ada pada Cube Broking. Dimana apa yang ingin ditampilkan pada chart tersebut dapat dipilih melalui menu field list yang otomatis akan terbuka saat menu Broking Chart dipilih.
155
Gambar 4.38 Tampilan Grafik broking Claims Chart akan menampilkan chart yang menunjukan total measure yang ada pada Cube Claim. Dimana apa yang ingin ditampilkan pada chart tersebut dapat dipilih melalui menu field list yang otomatis akan terbuka saat menu Claims Chart dipilih.
156
Gambar 4.39 Tampilan Grafik Claim Claims EB Chart akan menampilkan chart yang menunjukan total measure yang ada pada Cube Claim EB. Dimana apa yang ingin ditampilkan pada chart tersebut dapat dipilih melalui menu field list yang otomatis akan terbuka saat menu Claims Char EB dipilih.
157
Gambar 4.40 Tampilan Grafik Claim EB •
Pada menu help terdapat pilihan How To Use dan jika user memilih menu tersebut akan terbuka file dokumentasi prosedur penggunaan aplikasi yang berbentuk file PDF.
158
Gambar 4.41 Tampilan Prosedur Penggunaan Aplikasi
•
Pada menu About akan menampilkan halaman About yang menampilkan profil para pembuat aplikasi
159
Gambar 4.42 Tampilan menu about us 4.10.
Evaluasi Untuk mendapatkan umpan balik (feedback) dari pengguna aplikasi ini yaitu para
eksekutif, maka kami membuat kuesioner yang hasilnya dapat digunakan untuk mengukur tingkat kepuasan user terhadap aplikasi data warehouse ini dan mengukur sejauh mana aplikasi data warehouse ini sudah memenuhi kebutuhan para manajerial. Pertanyaan-pertanyaan kuesioner tersebut antara lain : 1. Apakah tampilan dari aplikasi ini user friendly? 2. Apakah aplikasi meningkatkan efisiensi kerja Anda? 3. Bagaimana performa aplikasi ini? 4. Bagaimana bentuk penyajian laporan? 5. Apakah data dalam laporan analisa sudah sesuai dengan kebutuhan? 6. Apakah M enu dan fungsi-fungsi sudah sesuai dengan kebutuhan?
160
7. Apakah pelatihan yang diberikan dapat dimengerti dengan baik? Tiap – tiap pertanyaan terdiri dari pilihan angka 1 sampai 5 yang mewakili tingkat kepuasan pengguna aplikasi. Angka 1 mewakili pilihan user yang tidak puas terhadap aplikasi ini dan angka 5 mewakili pilihan user yang sangat puas terhadap aplikasi ini. Kuesioner tersebut diisi sebanyak 16 orang yang terdiri dari para manajer dan supervisor. Hasil persentase kepuasan user terhadap aplikasi ini berdasarkan kuesioner yang diberikan kepada para eksekutif PT. Indosurance Broker Utama : 1. Apakah tampilan dari aplikasi ini user friendly? Tingkat kepuasan user terhadap tampilan dan kemudahan penggunaan aplikasi ini sebesar 81.25% 2. Apakah aplikasi meningkatkan efisiensi kerja Anda? Tingkat kepuasan user terhadap fungsi aplikasi yang memudahkan pekerjaan pengambilan keputusan mereka sebesar 87.5% 3. Bagaimana performa aplikasi ini? Tingkat kepuasan user terhadap performa aplikasi ini sebesar 81.25% 4. Bagaimana bentuk penyajian laporan? Tingkat kepuasan user terhadap bentuk penyajian laporan sebesar 80% 5. Apakah data dalam laporan analisa sudah sesuai dengan kebutuhan? Tingkat kepuasan user terhadap isi dari laporan yang sesuai dengan kebutuhan para manajerial sebesar 81.25% 6. Apakah M enu dan fungsi-fungsi sudah sesuai dengan kebutuhan?
161
Tingkat kepuasan user terhadap fungsi-fungsi aplikasi sesuai dengan kebutuhan para manajerial sebesar 86.25% 7. Apakah pelatihan yang diberikan dapat dimengerti dengan baik? Tingkat kepuasan user terhadap pelatihan penggunaan aplikasi dari kami sebesar 87.5%
Gambar 4.43 Grafik persentase hasil kuisioner Evaluasi sistem data warehouse ini dapat pula dibandingkan dengan sistem laporan yang sedang berjalan saat ini. Perbandingan sistem data warehouse dengan sistem laporan yang sedang berjalan :
162
Tabel 4.29 Perbandingan sistem yang ada dengan data warehouse
Pembanding 1. Kecepatan penyajian laporan
2. Efektifitas penyajian laporan
3. Isi laporan
4. Tampilan Chart / grafik
Sistem Laporan yang sedang berjalan
Sistem data warehouse
2-3 hari
30 menit
Untuk menampilkan laporan, harus menunggu semua pekerjaan pada hari tersebut selesai dilakukan terlebih dahulu, karena data-data untuk laporan menggunakan sumber yang sama dengan data transaksional.
Untuk menampilkan laporan tidak tergantung pada proses pemasukan data transaksional, karena laporan pada Sistem data warehouse berasal dari database yang berbeda dengan data transaksional.
M enyajikan data-data yang sederhana.Contohnya Tidak dapat menyajikan data broking maupun claim yang ada berdasarkan jenis resiko maupun kategori resiko.Hanya dapat menyajikan laporan berdasarkan polis asuransi.
Sederhana
M enyajikan data-data yang sesuai dengan keinginan user.Contohnya dapat menyajikan data broking maupun claim yang ada berdasarkan jenis resiko maupun kategori resiko.
Lebih menarik dan kompleks, dalam arti, chart/grafik dapat mempresentasikan data berdasarkan berbagai sudut pandang misalnya pelanggan/asuransi dan lainlain.
163
4.11.
Measure of Success Berdasarkan hasil survei atas penggunaan aplikasi, maka beberapa unsur yang telah dicapai dari sisi pengguna untuk mengukur tingkat kesuksesan proyek antara lain : i.
Penggunaan Data Warehouse Aplikasi data warehouse ini digunakan untuk keperluan reporting secara periodik dan diharapkan aplikasi ini dapat meningkatkan
produktifitas
para
manajerial
untuk
dapat
mengambil keputusan dengan lebih cepat dan akurat. ii.
Proyek selesai pada waktunya Waktu pengerjaan proyek selesai sesuai dengan waktu yang dijadwalkan yaitu selama 5 bulan yang berlangsung dari bulan September 2009 dan berakhir pada bulan Januari 2010.
iii.
Kepuasan pengguna Pengguna merasa puas dengan fitur, kemampuan dan kecepatan pengolahan laporan. Hal ini sesuai dengan hasil kuesioner kami yang telah dijawab oleh pihak PT. Indosurance Broker Utama yaitu Tingkat kepuasan user terhadap fungsi-fungsi aplikasi sesuai dengan kebutuhan para manajerial sebesar 86.25% dan Tingkat kepuasan user terhadap isi dari laporan yang sesuai dengan kebutuhan para manajerial sebesar 81.25%
164
iv.
Permasalahan terselesaikan Permasalahan yang dihadapi oleh para manajerial seperti yang telah disebutkan sebelumnya yaitu : y Sulitnya mendapatkan laporan yang akurat khususnya pada bagian broking dan claims. y Karena tidak adanya laporan yang akurat maka pengambilan keputusan sering kali tidak sesuai dengan permasalahan yang terjadi y Pengumpulan data yang memakan waktu lama dalam pembuatan laporan Permasalahan yang dihadapi dapat diselesaikan dan memenuhi kebutuhan pengguna. Hal ini sesuai dengan hasil kuesioner kami dimana Tingkat kepuasan user terhadap performa aplikasi ini sebesar 81.25% dan Tingkat kepuasan user terhadap fungsi aplikasi yang memudahkan pekerjaan pengambilan keputusan mereka sebesar 87.5%.
