lib.ui.ac.idlib.ui.ac.id/file?file=digital/2015-3/20392967-ta-alexander rudy.pdflib.ui.ac.id

UNIVERSITAS INDONESIA

IMPLEMENTASI DATAMART DAN OLAP DALAM PELAPORAN DAN MONITORING PENYISIHAN

CADANGAN KERUGIAN PENURUNAN NILAI (CKPN) PADA PORTFOLIO PEMBIAYAAN BANK ‘X’ SESUAI DENGAN

PSAK 50/55

KARYA AKHIR

ALEXANDER RUDY GUNAWAN

1106041804

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA JULI 2014

Implementasi datamart…., Alexander Rudy Gunawan, FASILKOM UI, 2014

HALAMAN JUDUL

UNIVERSITAS INDONESIA

IMPLEMENTASI DATAMART DAN OLAP DALAM PELAPORAN DAN MONITORING PENYISIHAN

CADANGAN KERUGIAN PENURUNAN NILAI (CKPN) PADA PORTFOLIO PEMBIAYAAN BANK ‘X’ SESUAI DENGAN

PSAK 50/55

KARYA AKHIR

Diajukan sebagai salah satu syarat memperoleh gelar Magister Teknologi Informasi

ALEXANDER RUDY GUNAWAN

1106041804

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA JULI 2014


ii

HALAMAN PERNYATAAN ORISINALITAS

Karya Akhir ini adalah hasil karya saya sendiri,

dan semua sumber, baik yang dikutip maupun dirujuk

telah saya nyatakan dengan benar.

Nama : Alexander Rudy Gunawan

NPM : 1106041804

Tanda Tangan : ……………………………

Tanggal : 14 Juli 2014


iii

HALAMAN PENGESAHAN

Karya Akhir ini diajukan oleh : Nama : Alexander Rudy Gunawan NPM : 1106041804 Program Studi : Magister Teknologi Informasi Judul Karya Akhir : Implementasi Datamart dan OLAP dalam

Pelaporan dan Monitoring Penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) pada Portfolio Pembiayaan Bank X sesuai dengan PSAK 50/55.

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia.

DEWAN PENGUJI

Pembimbing : Yova Ruldeviyani, M. Kom.

Penguji : Dr. Achmad Nizar Hidayanto.S.Kom.,M.Kom

Penguji : Dr. Ir. Petrus Mursanto M.Sc

Ditetapkan di : Jakarta Tanggal : 2 Juli 2014


iv

KATA PENGANTAR

Puji syukur saya haturkan kepada Tuhan Yang Maha Esa yang telah

memberikan berkat dan rahmat-Nya sehingga saya dapat menyelesaikan Karya

Akhir ini. Saya menyadari, tanpa bantuan dari berbagai pihak, sangatlah sulit bagi

saya untuk menyelesaikannya. Dalam penyusunan, penulis banyak menemui

kesulitan dan hambatan. Namun karena bantuan berbagai pihak hingga penulis

dapat menyelesaikan Karya Akhir ini.

Dalam kesempatan ini penulis megucapkan terimakasih atas segala

dukungan dan bantuan dari berbagai pihak yang sudah diberikan kepada:

1. Ibu Yova Ruldeviyani, M.Kom, selaku dosen pembimbing yang telah

menyediakan waktu, tenaga, dan pikiran untuk mengarahkan saya dalam

penyusunan Karya Akhir ini;

2. Pihak perusahaan objek studi, yang telah membantu memberikan data

penelitian Karya Akhir ini;

3. Dosen pengajar, Dosen penguji Bapak Dr. Achmad Nizar

H.S.Kom.,M.Kom dan Dr. Ir. Petrus Mursanto M.Sc serta staf MTI UI

yang telah memberikan ilmu dan pengetahuan serta berbagai wawasan

dan dukungan yang berkesinambungan;

4. Teman teman kampus dan khususnya MTI UI 2011SB untuk

kebersamaan, dukungan dan diskusi yang membantu saya dalam

penulisan; dan

5. Seluruh pihak yang tidak dapat saya sebutkan satu per satu yang telah

memberikan dukungan kepada saya dalam menyelesaikan Karya Akhir ini.

Saya mohon maaf apabila saya hanya dapat memberikan ucapan terima

kasih dan doa. Semoga Allah SWT membalas segala kebaikan semua pihak yang

telah membantu.Semoga Karya Akhir ini membawa manfaat bagi kemajuan ilmu

pengetahuan.

Jakarta, 14 Juli 2014

Penulis


v

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini: Nama : Alexander Rudy Gunawan NPM : 1106041804 Program Studi : Magister Teknologi Informasi Departemen : - Fakultas : Ilmu Komputer Jenis Karya : Karya Akhir Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Noneksklusif (Non-exclusive Royalty- Free Right) atas karya ilmiah saya yang berjudul : "Implementasi Datamart dan OLAP dalam Pelaporan dan Monitoring Penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) pada Portfolio Pembiayaan Bank X sesuai dengan PSAK 50/55" Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Noneksklusif ini, Universitas Indonesia berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat, dan mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di : Jakarta Pada tanggal : 14 Juli 2014

Yang menyatakan

(Alexander Rudy Gunawan)


vi Universitas Indonesia

ABSTRAK

Nama : Alexander Rudy Gunawan Program Studi : Magister Teknologi Informasi Judul : Implementasi datamart dan OLAP dalam Pelaporan dan

Monitoring penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) pada portfolio Pembiayaan Bank ‘X’ sesuai dengan PSAK 50/55.

Implementasi PSAK 50/55 di masing-masing Bank di Indonesia merupakan salah satu syarat regulatory compliance dari Bank Indonesia dan Ikatan Akuntan Indonesia. Salah satu cakupan dari PSAK 50/55 adalah Penyisihan Kerugian Kredit (Loan-Loss Provisionin / Loan Impairment) atau dikenal dengan istilah Cadangan Kerugian Penurunan Nilai (CKPN) yang wajib dibentuk oleh Bank, sebagai akibat dari penyaluran kredit atau pembiayaan.

Perhitungan CKPN membutuhkan data pembiayaan dari berbagai source system (core banking) dalam kurun waktu minimal 3 tahun. Oleh karena itu tantangan yang dihadapi Bank adalah kesiapan dalam menyusun laporan pembentukan CKPN secara tepat waktu dan akurat sesuai dengan metodologi perhitungan yang disyaratkan oleh regulator. Tantangan lainnya adalah terkait dengan pengambilan keputusan akibat volatilitas pembentukan CKPN sesuai dengan aturan PSAK 50/55. Volatilitas tersebut akan berpengaruh kepada tingkat profitabilitas Bank itu sendiri dan potensi kerugian risiko kredit. Apabila penyisihan terlalu besar, maka berdampak pada profitabilitas bank, sedangkan apabila penyisihan terlalu kecil, maka dapat meningkatkan risiko kredit bank khususnya apabila kredit yang bermasalah meningkat.

Oleh karena itu dibutuhkan datamart PSAK 50/55 yang mampu mengumpulkan berbagai sumber data pembiayaan yang dapat digunakan untuk perhitungan CKPN sesuai dengan ketentuan PSAK 50/55. Dengan adanya datamart ini penyusunan laporan penyisihan kerugian kredit (CKPN) oleh Bank X dapat dicapai secara tepat waktu dan akurat. Implementasi datamart juga merupakan fondasi dalam penerapan OLAP yang dapat memberikan jawaban atas tantangan pengambilan keputusan, sehingga dapat memberikan efisiensi dan efektivitas bagi Bank X.

Penelitian dilakukan dengan pengumpulan data, pemahaman kebutuhan bisnis dan informasi, perancangan arsitektur datawarehouse dan perancangan dan implementasi datamart, termasuk proses ETL dan penerapan OLAP. Hasil penelitian ini berupa implementasi datamart PSAK 50/55 dan penerapan OLAP dalam pelaporan dan monitoring penyisihan CKPN pada portfolio pembiayaan sesuai dengan PSAK 50/55.

Kata kunci: data warehouse, datamart, ETL, OLAP xv+ 191 halaman; 27 gambar; 56 tabel; 11 lampiran


vii Universitas Indonesia

ABSTRACT

Name : Alexander Rudy Gunawan Study Program : Master of Information Technology Title : Datamart and OLAP Implementation for Reporting and

Monitoring Allowance of Impairment Provision (CKPN) on Financing Portfolio Bank ‘X’ in accordance with PSAK 50/55

Implementation of PSAK 50/55 in each Bank in Indonesia is one of the

regulatory compliance requirements from Bank Indonesia (BI) and Indonesia Accountants Association (IAI). The scope of PSAK 50/55 is the allowance for credit losses or known as CKPN.

In order to calculate loan impairment allowance, Banks need to consolidate from variety of source systems (core banking) with at least 3 years loan historical data. The challenge faced is the readiness of Banks in preparing the report of impairment allowance in timely and accurate manner. Other challenge is the decision making made by the Bank related to the volatility of impairment provision as a result of PSAK 50/55. This volatility will affect Bank’s profitability and credit risk exposure. If the allowance is too high, it impact on the profitability, whereas if the allowance is too small, credit risk is impacted, particularly when the bad debt is also increase.

Therefore it required a datamart, which is able to consolidate a variety of data sources in a single view, spesific for the purpose of calculation impairment allowance in accordance with PSAK 50/55. Preparation of the report can be achieved on time and provide accurate result along with analytical capability for decision making support. Implementation datamart is also the foundation for OLAP application which can answers to the challenges of decision making. Those all benefits provide efficiencies and effectiveness of the Bank X.

This research start with data collection, understanding the requirements of business and information, design of datawarehouse architecture and datamart design and implementation, including ETL processes and end with OLAP application. The result of this research is the implementation of PSAK 50/55 datamart and OLAP for the reporting and monitoring allowance for impairment in accordance with PSAK 50/55.

Keywords : data warehouse, datamart, ETL,OLAP xv+ 191 pages; 27 figures; 56 tables; 11 attachments


viii Universitas Indonesia

DAFTAR ISI

HALAMAN JUDUL ........................................................................................... i HALAMAN PERNYATAAN ORISINALITAS ............................................... ii HALAMAN PENGESAHAN ........................................................................... iii KATA PENGANTAR ....................................................................................... iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI ......................... v ABSTRAK ......................................................................................................... vi ABSTRACT ..................................................................................................... vii DAFTAR ISI ................................................................................................... viii DAFTAR GAMBAR ......................................................................................... xi DAFTAR TABEL ........................................................................................... xiii BAB 1 PENDAHULUAN................................................................................... 1 1.1 Latar Belakang............................................................................................ 1 1.2 Rumusan Masalah ....................................................................................... 3 1.3 Tujuan dan Manfaat Penelitian .................................................................... 7 1.4 Ruang Lingkup Penelitian ........................................................................... 7 1.5 Sistematika Penulisan ................................................................................. 8 BAB 2 TINJAUAN PUSTAKA ....................................................................... 10 2.1 Datawarehouse dan Datamart .................................................................... 10

2.1.1 Pengertian Data warehouse dan Datamart ....................................... 10

2.1.2 Extraction Transformation Loading (ETL) ....................................... 12

2.1.3 Keuntungan Data Warehouse ........................................................... 15

2.1.4 Isu Data warehouse.......................................................................... 16

2.2 Metodologi Perancangan Data Warehouse/Datamart ................................ 18 2.3 Arsitektur Datamart .................................................................................. 21 2.4 Konsep Permodelan Data Warehouse ....................................................... 23

2.4.1 Star Schema ..................................................................................... 23

2.4.2 Snowflake Schema ........................................................................... 24

2.4.3 Schema Galaxy / Fact Constellation ................................................. 25

2.4.4 Slowly Changing Dimension (SCD) ................................................. 26

2.5 Business Intelligence dan OLAP ............................................................... 28 2.5.1 On-Line Analytical Processing (OLAP) ........................................... 29

2.5.2 Tipe-tipe operasi OLAP ................................................................... 30

2.6 Penelitian Sebelumnya .............................................................................. 31 2.7 Pedoman Akuntansi Perbankan Indonesia (PAPI) ..................................... 35

2.7.1 Latar Belakang ................................................................................. 35

2.7.2 Tujuan dan Ruang Lingkup .............................................................. 35

2.7.3 Perbedaan Perhitungan Pembentukan Penyisihan Aktiva Sebelum dan Sesudah Menggunakan PSAK 50 dan 55 ......................................... 37

2.7.4 Pengertian Penurunan Nilai .............................................................. 38


ix Universitas Indonesia

2.7.5 Kriteria Evaluasi Penurunan Nilai .................................................... 39

2.7.6 Penurunan Nilai dan Tidak Tertagihnya Aset Keuangan ................... 41

BAB 3 METODOLOGI PENELITIAN .......................................................... 43 3.1 Perumusan masalah................................................................................... 44 3.2 Studi Literatur ........................................................................................... 45 3.3 Pengumpulan Data .................................................................................... 45 3.4 Analisis kebutuhan bisnis dan informasi ................................................... 46 3.5 Perancangan Arsitektur Datamart .............................................................. 47 3.6 Perancangan dan Implementasi Datamart .................................................. 47 3.7 Implementasi OLAP ................................................................................. 48 3.8 Kesimpulan dan Saran .............................................................................. 48 BAB 4 ANALISA, PERANCANGAN DAN IMPLEMENTASI DATAMART

PSAK 50/55 ......................................................................................... 49 4.1 Identifikasi Kebutuhan Bisnis ................................................................... 49

4.1.1 Analisa Kebutuhan Informasi dan Proses Bisnis ............................... 49

4.1.2 Analisa Sumber Data ........................................................................ 63

4.1.3 Analisa Transformasi sesuai dengan kebutuhan bisnis ...................... 68

4.2 Perancangan Arsitektur DataMart ............................................................. 78 4.3 Perancangan Permodelan Data Warehouse ............................................... 84

4.3.1 Pemilihan Proses Bisnis (Choosing the process) ............................... 84

4.3.2 Pemilihan Grain (Choosing the Grain) ............................................. 86

4.3.3 Identifikasi dan Penyesuaian Dimensi (Identifiying and Conforming the Dimensions) ............................................................................... 89

4.3.4 Pemilihan Fakta (Choosing the Fact) ............................................... 92

4.3.5 Penyimpanan Pre-Calculation pada Tabel Fakta (Storing Pre-Calculation in the Fact Tabel) ......................................................... 92

4.3.6 Melengkapi Tabel Dimensi (Rounding Out the Dimension Tabel) .... 95

4.3.7 Pemilihan Durasi dan Basis data (Choosing the duration of the database) ....................................................................................... 105

4.3.8 Melacak Perubahan Dimension Secara Perlahan (Tracking Slowly Changing Dimensions)................................................................... 105

4.3.9 Memutuskan Prioritas dan Mode dari Query (Deciding the Query Priorities and the Query Modes) .................................................... 108

4.4 Proses ETL ............................................................................................. 111 4.4.1 Proses Ekstrak dan Transformasi Data Staging .............................. 112

4.4.2 Proses Transformasi dan Load Tabel Dimensi ............................... 132

4.4.3 Proses Transformasi dan Load ke Tabel Fakta ............................... 141


x Universitas Indonesia

BAB 5 IMPLEMENTASI OLAP .................................................................. 152 5.1 Implementasi .......................................................................................... 152

5.1.1 Informasi Pembiayaan .................................................................... 153

5.1.2 Informasi Cadangan Kerugian Penurunan Nilai .............................. 158

5.2 Uji Coba ................................................................................................. 167 BAB 6 KESIMPULAN DAN SARAN ........................................................... 169 6.1 Kesimpulan............................................................................................. 169 6.2 Saran ...................................................................................................... 170 DAFTAR PUSTAKA ..................................................................................... 172 DAFTAR LAMPIRAN .................................................................................. 174


xi Universitas Indonesia

DAFTAR GAMBAR

Gambar 2.1 Datawarehouse Model (Kimball, 2005) ....................................... 11

Gambar 2.3 Perancangan Star Schema ............................................................ 24

Gambar 2.4 Perancangan Skema Snow Flake ................................................. 25

Gambar 2.5 Perancangan Skema Fact Constellation(Conolly & Begg, 2005) . 26

Gambar 3.1 Metode Penelitian ....................................................................... 43

Gambar 4.1 Alur Proses Perhitungan CKPN ................................................... 61

Gambar 4.2 Hasil Rancangan Arsitektur Data Mart PSAK 50/55 .................... 81

Gambar 4.3 Skema Pembiayaan (Loan) ........................................................ 103

Gambar 4.4 Skema Cadangan Kerugian Penurunan Nilai (CKPN) ................ 104

Gambar 4.5 Ekstraksi dan Transformasi Data Pembiayaan ke masing-masing

tabel .......................................................................................... 112

Gambar 4.6 Overal Proses Transformasi Perhitungan Impairment (CKPN) .. 122

Gambar 5.1 Struktur Cube Informasi Pembiayaan ........................................ 154

Gambar 5.2 Presentasi Laporan rasio NPL per masing-masing cabang ......... 155

Gambar 5.3 Presentasi Laporan Pembiayaan berdasarkan lamanya jatuh tempo

.................................................................................................. 156

Gambar 5.4 Presentasi Laporan Pembiayaan berdasarkan pergerakan

kolektibilitas ............................................................................. 157

Gambar 5.5 Presentasi summary Analisa Persentase pergerakan kolektibilitas

.................................................................................................. 157

Gambar 5.6 Struktur Cube pada informasi CKPN ......................................... 159

Gambar 5.7 Presentasi Laporan monitoring CKPN Forecast, CKPN Aktual,

PPAP,dan Impaired Loan Ratio berdasarkan cabang, main branch

dan area ..................................................................................... 160

Gambar 5. 8 Presentasi Drill down dari Area ke Main Branch untuk Laporan

monitoring CKPN Forecast, CKPN Aktual, PPAP, dan Impaired

Loan Ratio berdasarkan cabang, main branch dan area .............. 161

Gambar 5. 9 Presentasi Drill down dari Main Branch ke Branch dengan CKPN

Total terbesar di periode Februari 2014. .................................... 162


xii Universitas Indonesia

Gambar 5.10 Presentasi Drill down dari Branch ke daftar customer dengan

CKPN Total terbesar di periode Februari 2014. ......................... 163

Gambar 5.11 Presentasi laporan Trend PD dan LGD ...................................... 163

Gambar 5.12 Presentasi laporan perbandingan PPAP dengan CKPN .............. 164

Gambar 5.13 Presentasi laporan Movement CKPN Charged terbesar

dikelompokkan berdasarkan cabang pada periode April 2014 .... 164

Gambar 5.14 Presentasi laporan Movement CKPN Released terbesar

dikelompokkan berdasarkan cabang pada periode April 2014 .... 165

Gambar 5.15 Presentasi laporan collective Impairment berdasarkan group of

Impairment ................................................................................ 165

Gambar 5.16 Presentasi laporan collective Impairment berdasarkan Segmentasi

Pembiayaan pada bulan April 2014 ........................................... 166


xiii Universitas Indonesia

DAFTAR TABEL

Tabel 2.1 Contoh penerapan SCD Type 6 ................................................... 27

Tabel 4.1 Tabel Daftar Kebutuhan Informasi dan Kebutuhan Analisa ......... 55

Tabel 4.2 Tabel Sumber Data Yang Akan Digunakan ................................. 64

Tabel 4.3 Tabel sumber tabel dan tujuan tabel serta transformation rule yang

melekat sebagai persiapan data CKPN ......................................... 69

Tabel 4.4 Tabel Analisa Perbandingan Arsitektur Inmon dan Kimball serta

keterangan dalam arsitektur datamart PSAK 50/55 ...................... 78

Tabel 4.5 Tabel pemilihan grain atas informasi yang dapat dianalisa........... 88

Tabel 4.6 Tabel Grain dan Dimensi pada Pembiayaan ................................ 90

Tabel 4.7 Tabel Grain dan Dimensi pada Pembentukan CKPN ................... 90

Tabel 4.8 Tabel Identifikasi Dimensi .......................................................... 91

Tabel 4.9 Tabel Penjelasan Dimensi ........................................................... 95

Tabel 4.10 Deskripsi Tabel DIM_PERIOD ................................................... 97

Tabel 4.11 Deskripsi Tabel DIM_AKAD ...................................................... 97

Tabel 4.12 Deskripsi Tabel DIM_SEGMENT............................................... 98

Tabel 4.13 Deskripsi Tabel DIM_IMPAIRMENT_GROUP ......................... 98

Tabel 4.14 Deskripsi Tabel DIM_CURRENCY ............................................ 99

Tabel 4.15 Deskripsi Tabel DIM_AREABRANCH ...................................... 99

Tabel 4.16 Deskripsi Tabel DIM_MAINBRANCH ...................................... 99

Tabel 4.17 Deskripsi Tabel DIM_BRANCH ............................................... 100

Tabel 4.18 Deskripsi Tabel DIM_COLLECTIBILITY................................ 100

Tabel 4.19 Deskripsi Tabel DIM_PRODUCT ............................................. 100

Tabel 4.20 Deskripsi Tabel DIM_COLLECTABILITY_MOVEMENT ...... 101

Tabel 4.21 Deskripsi Tabel DIM_MATURITY_PROFILE ......................... 101

Tabel 4.22 Deskripsi Tabel DIM_IMPAIRMENT_FLAG .......................... 102

Tabel 4.23 Deskripsi Tabel DIM_CUSTOMER .......................................... 102

Tabel 4.24 Durasi dan Basis Data Datamart PSAK 50/55 ........................... 105

Tabel 4.25 Tabel Pelacakan Perubahan Dimensi ......................................... 106

Tabel 4.26 Tabel Estimasi Data Staging pada PSAK_MASTER_ACCOUNT

untuk periode Mei 2010-Desember 2013 ................................... 109


xiv Universitas Indonesia

Tabel 4.27 Struktur Tabel PSAK_MASTER_ACCOUNT .......................... 113

Tabel 4.28 Struktur Tabel PSAK_IMPR_OVERRIDES .............................. 117

Tabel 4.29 Struktur Tabel TBLT_PAYMENTEXPECTED ........................ 118

Tabel 4.30 Struktur Tabel PSAK_EXPECTED_RECOV_UPLOAD .......... 119

Tabel 4.31 Struktur Tabel PSAK_COLL_SHORTFALL_UPLOAD ........... 119

Tabel 4.32 Struktur Tabel PSAK_CKPN_TARGET ................................... 119

Tabel 4.33 Struktur Tabel PSAK_INDIVIDUAL_IMPAIRMENT ............. 120

Tabel 4.34 Struktur Tabel PSAK_DPD_MASTER ..................................... 120

Tabel 4.35 Struktur Tabel PSAK_DPD_MASTER_HEADER .................... 121

Tabel 4.36 Tabel Transformasi PSAK_ENR ............................................... 123

Tabel 4.37 Tabel Transformasi PSAK_LGD (Flow Rate Calculation) ........ 124

Tabel 4.38 Tabel Transformasi PSAK_LGD (Average Flow Rate) ............. 125

Tabel 4.39 Tabel Transformasi PSAK_LGD (Flow To Loss Calculation) ... 126

Tabel 4.40 Tabel Transformasi PSAK_ENR_MIGRATION ....................... 128

Tabel 4.41 Tabel Transformasi PSAK_FLOWRATE_MIGRATION .......... 129

Tabel 4.42 Tabel Transformasi PSAK_COMPOUND_FLOW_TO_LOSS . 130

Tabel 4.43 Tabel Transformasi PSAK_LGD ............................................... 130

Tabel 4.44 Tabel Transformasi PSAK_MASTER_ACCOUNT .................. 131

Tabel 4.45 Tabel Sumber, Tujuan dan Rules Dimensi Customer ................. 133

Tabel 4.46 Tabel Sumber, Tujuan dan Rules Dimensi Segment .................. 135

Tabel 4.47 Tabel Sumber, Tujuan, dan Rules Dimensi Impairment Group .. 136

Tabel 4.48 Tabel Sumber, Tujuan, dan Rules Dimensi Area ....................... 137

Tabel 4.49 Tabel Sumber, Tujuan, dan Rules Dimensi Cabang Utama ........ 138

Tabel 4.50 Tabel Sumber, Tujuan dan Rules Dimensi Cabang .................... 139

Tabel 4.51 Tabel Sumber, Tujuan dan Rules Dimensi Product .................... 140

Tabel 4.52 Tabel Sumber, Tujuan, dan Rules Dimensi Maturity Profile ...... 141

Tabel 4.53 Tabel transformasi FACTLOANACCOUNT sebagai tabel input

sebelum load ke tabel FACT_LOAN......................................... 143

Tabel 4.54 Tabel Load ke Tabel Fakta Pembiayaan (FACT_LOAN) .......... 145

Tabel 4.55 Tabel Load ke Tabel Fakta CKPN (FACT_CKPN) ................... 148


1 Universitas Indonesia

BAB 1

PENDAHULUAN

1.1 Latar Belakang

Perbankan merupakan urat nadi perekonomian di seluruh negara, tidak terkecuali

di Indonesia. Peran perbankan nasional dalam membangun perekonomian

merupakan salah satu sektor yang diharapkan berperan aktif dalam menunjang

kegiatan pembangunan nasional atau regional. Peran Perbankan diwujudkan

dalam fungsi utamanya sebagai lembaga intermediasi atau institusi perantara

antara debitor dan kreditor, sebagai lembaga perantara yang menghimpun dana

dan menempatkannya dalam bentuk aktiva produktif, dalam hal ini kredit yang

diberikan. Penyaluran kredit atau pembiayaan merupakan kegiatan usaha yang

mendominasi pengalokasian dana bank. Pemberian kredit yang dilakukan oleh

bank mengandung resiko yaitu berupa tidak lancarnya pembayaran kredit atau

dengan kata lain kredit bermasalah (NonPerforming Loan) sehingga akan

mempengaruhi kinerja bank. Untuk meminimalkan potensi kerugian dari kredit

bermasalah tersebut yaitu dengan menjagakualitas aktiva dan membentuk

cadangan kerugian penurunan nilai (CKPN). Dengan besarnya kredit yang

diberikan kepada nasabah, bank mempunyai risiko pengembalian piutang yang

macet, hal tersebut dapat meningkatkan kredit bermasalah (Non Performing Loan)

maka akibatnya bank harus menyediakan cadangan kerugian yang cukup.

Implementasi PSAK (Pernyataan Standar Akuntansi Keuangan) 50/55 di masing-

masing Bank di Indonesia merupakan salah satu syarat regulatory compliance dari

Bank Indonesia dan Ikatan Akuntan Indonesia, ditunjukkan melalui Surat Edaran

Bank Indonesia No. 11/4/DPNP mengenai Pelaksanaan Pedoman Akuntansi

Perbankan Indonesia (PAPI) dan No. 15/26/DPbs mengenai pelaksanaan Pedoman

Akuntansi Perbankan Syariah Indonesia (PAPSI). Salah satu cakupan dari PSAK

50/55 adalah Penyisihan Kerugian Kredit (Loan-Loss Provisioning atau/ Loan

Impairment) atau dikenal dengan perhitungan Cadangan Kerugian Penurunan

Nilai (CKPN). Sebagaimana diketahui bahwa tujuan daripada penyisihan kerugian


2

Universitas Indonesia

kredit adalah untuk menutup kemungkinan kerugian yang timbul sehubungan

dengan alokasi dana ke dalam pemberian kredit.

Terhitung 1 Januari 2014 Bank harus mengukur penurunan nilai dan membentuk

CKPN berdasarkan data historis kerugian kredit yang sudah terjadi atau incurred

loss. Cadangan Kerugian Penurunan Nilai (CKPN) ini dipakai sebagai ganti dari

perhitungan PPAP (Penyisihan Penghapusan Aktiva Produktif). Pada aturan PPAP

Bank hanya menyisihkan cadangan kerugian dengan maksimum berdasarkan

persentase tertentu untuk setiap kualitas kredit.

Adapun CKPN dihitung berdasarkan 2 kategori; Kategori pertama adalah

perhitungan CKPN secara individual per level debitur, dimana pembentukan atau

penyisihan dana dari kredit dinilai dari hasil evaluasi kredit debitur yang

dilakukan oleh internal bank sesuai dengan kebijakan yang berlaku. Maka kita

harus menentukan terlebih dahulu kredit dari debitur mana saja yang mengalami

penurunan nilai, misalnya: debitur mengalami wanprestasi atau mempunyai

tunggakan pembayaran oleh debitur, restrukturisasi kredit oleh Bank atau kondisi

ekonomi yang berkorelasi dengan wanprestasi atas aset dalam kelompok tersebut.

Setelah itu, maka besarnya nilai cadangan dana kredit itu ditentukan dari selisih

antara nilai tunggakan kredit debitur tersebut sebelum dan sesudah terjadinya

penurunan nilai. Kategori kedua adalah perhitungan CKPN secara kolektif, yang

melibatkan perkalian beberapa komponen, yakni potensi gagal bayar (probability

of default) dikalikan jumlah kredit yang bersangkutan. Komponen lainnya loss

given default (LGD) yang merupakan porsi kerugian riil akibat gagal bayar yang

benar-benar tak tertagih, di luar tingkat kembalian tagihan (recovery rate).

Probability of default yang dihitung dari pengalaman kerugian yang sudah terjadi

berdasarkan data historis setiap jenis kredit bank tersebut minimal selama 2

sampai 5 tahun terakhir.

Salah satu isu yang penting adalah mengenai kesiapan bank dalam memenuhi

syarat regulatory compliance dari regulator dalam menyiapkan laporan

pembentukan CKPN secara tepat waktu dan akurat sesuai dengan metodologi

perhitungan yang disyaratkan. Isu yang penting lainnya terkait dengan


3


pengambilan keputusan terkait dengan volatilitas pembentukan CKPN sesuai

dengan PSAK 50/55, yang mana akan berpengaruh kepada tingkat profitabilitas

Bank itu sendiri dan potensi kerugian risiko kredit. Apabila penyisihan terlalu

besar, maka dampaknya kepada profitabilitas bank itu sendiri, sedangkan apabila

penyisihan terlalu kecil, maka dapat meningkatkan risiko kredit Bank, terutama

apabila kredit yang bermasalah meningkat.

Untuk dapat menghitung CKPN pada portfolio pembiayaan, dibutuhkan beberapa

data dari berbagai sumber Core Banking System. Namun apabila data tersebut

tidak tersedia dibutuhkan input secara manual. Oleh karena itu penelitian yang

dilakukan adalah merancang dan mengimplementasikan datamart PSAK 50/55

sebagai syarat kepatuhan (compliance) Bank X kepada regulator, dan untuk

mendukung pengambilan keputusan dalam penentuan kebijakan perhitungan

CKPN sesuai dengan PSAK 50/55. Untuk memenuhi kebutuhan penyusunan

laporan CKPN yang cepat dan pengambilan keputusan, maka dibuatlah

implementasi datamart. Pemilihan implementasi datamart dikarenakan

kebutuhannya spesifik untuk Departemen Akuntansi. Datamart merupakan

kumpulan dari berbagai data source dan dibuat untuk tujuan pelaporan. Analisis

yang bersifat read only digunakan sebagai fondasi dari penunjang keputusan.

Selanjutnya proses pelaporan dan analisa dapat menggunakan fitur OLAP (Online

Analytical Processing) dan fitur query data tanpa menganggu database

operasional, sehingga penggunaan datamart dapat memberikan efisiensi dan

efektifitas bagi Bank X.

1.2 Rumusan Masalah

Implementasi PSAK 50/55 terkait pengaturan penentuan nilai CKPN, membawa

dampak yang tidak mudah bagi perbankan,antara lain :

1. Ketersediaan data yang diharuskan oleh regulator dalam perumusan CKPN

adalah data tunggakan pokok, data histori pembayaran, day past due,

kolektibilitas, write off, recovery, agunan, data histori nomor rekening 2-5

tahun ke belakang, dan lain lain. Banyaknya data berkisar +/-150 ribu records

per level nomor kartu pembiayaan setiap bulannya dan data tersebut

dikumpulkan dari berbagai unit bisnis dan berbagai source system (credit card


4


operations, mortgage systems, Joint Finance, core financing system dan

informasi dari loans operations) dalam format yang beragam (flat file ataupun

database ) serta tingkat granularitas data yang berbeda untuk masing-masing

sumber data. Hal tersebut menyebabkan konsolidasi pembuatan laporan

menjadi sulit dan memakan waktu yang cukup lama.

2. Informasi mengenai nilai CKPN tidak tersedia secara langsung pada sumber

data, sehingga diperlukan proses perhitungan tertentu sesuai dengan aturan

PSAK 50/55 dengan menggunakan seluruh data pembiayaan.

3. Keharusan dari Bank Indonesia untuk dapat menyediakan laporan mengenai

CKPN ini maksimal pada setiap tanggal 5, dimana waktu ditentukan sepihak

saja oleh Bank Indonesia sebagai regulator. Termasuk tuntutan untuk hasil

laporan yang tepat dan cepat, dalam mengambil serta mengolah data data

pembiayaan sesuai dengan regulasi dari Bank Indonesia. Karena

ketidaktepatan (baik data maupun waktu) dapat berakibat pinalti dari pihak

Bank Indonesia kepada bank pelapor.

4. Banyaknya permintaan laporan dari masing-masing unit kerja (credit

operations, compliance, manajemen risiko dan accounting) dengan format

yang beragam baik dari sisi ringkasan dan rincian dan kadangkala bersifat

mendadak (adhoc). Hal tersebut sangat memerlukan upaya besar untuk

menyiapkan dan menyajikan data dimaksud secara cepat dan lengkap.

5. Ditambah belum adanya fasilitas yang dapat dipergunakan untuk menyediakan

dan menyajikan data secara interaktif dengan berbagai skenario sesuai dengan

kebutuhannya, maka diperlukan tambahan effort dalam persiapan pelaporan

kepada pucuk pimpinan. Hal ini membuat informasi yang diperoleh menjadi

sulit diolah dan dianalisis oleh pihak eksekutif. Aplikasi OLAP dianggap

perlu karena pada perusahaan tersebut belum terdapat alat yang dapat melihat

trend perkembangan pembentukan CKPN dari waktu ke waktu secara cepat.

6. Untuk dapat melihat trend perkembangan seperti ini dan adanya kebijakan dari

Manajemen Risiko untuk memonitor kualitas debitur setiap 6 bulanan. Maka

dari itu diperlukan waktu dan effort tambahan untuk pengumpulan dan

pemrosesan ulang dari unit kerja manajemen risiko, dimana sumber datanya

adalah berasal dari data laporan bulanan yang sifatnya rincian yang cukup


5


besar jumlah datanya (+/- 150-300 ribu records per satu tanggal bulan

pelaporan) dan keterbatasan kapabilitas tools yang ada sekarang yaitu

Microsoft Excel untuk senantiasa menampung dan memonitor data histori

selama 6 bulanan. Hal ini membuat informasi yang diperoleh menjadi sulit

diolah dan dianalisis oleh pihak eksekutif.

Dari beberapa uraian permasalahan tersebut, maka Bank membutuhkan

tersedianya datamart spesifik untuk kebutuhan divisi Akuntasi dan Keuangan

serta divisi Manajemen Risiko yang dapat membantu untuk mengumpulkan,

menyimpan, menganalisis dan menyediakan akses ke data guna membantu

pengguna mengambil keputusan secara akurat dengan melakukan berbagai

aktivitas diantaranya, sistem pendukung keputusan, query, pelaporan, dan online

analytical processing (OLAP).

Perancangan datamart PSAK 50/55 dan OLAP akan menampilkan monitoring

dan analisa dari hasil pembentukan CKPN berdasarkan kalkulasi PSAK 50/55

secara bank wide yang meliputi informasi:

1. Laporan Total Pembiayaan berdasarkan Cabang, berdasarkan Produk dan

berdasarkan segment. Laporan Total Pembiayaan berdasarkan Tanggal Jatuh

Tempo.

2. Laporan distribusi pembiayaan yang mengalami perubahan kolektibilitas(ke

lebih baik atau lebih buruk atau pembiayaan tersebut matured) dari periode

pelaporan bulan ini dan bulan sebelumnya per masing-masing produk,

segment, mata uang, cabang.

3. Laporan RatioNon Performing Loan per masing-masing cabang.

4. Laporan Probability Default(PD) dan Loss Given Default (LGD) Trend,

dimana laporan ini berfungsi untuk menampilkan kecendrungan perubahan

nilai PD dari jangka waktu periode tertentu berdasarkan segementasi

pengelompokkan pembiayaan dan masing-masing kolektibilitas.

5. Laporan CKPN Kolektif / Collective Assesment Provision yang berisi hasil

dari perhitungan CKPN secara Kolektif berdasarkan kelompokdari group of

impairment.


6


6. Laporan Perbandingan antara CKPN Kolektif / Collective Assesment

Provision dengan PPAP (Penyisihan Penghapusan Aktiva Produktif)

berdasarkan segmentasi, cabang, produk, dan collective group impairment.

7. Laporan mengenai nilai variance antara CKPN actual dan CKPN forecast

untuk setiap cabang dan segmentasi pembiayaan.

8. Laporan Impairment Loan Ratio per masing-masing cabang. Impairment

Ratio ini didapat dengan membagi Total CKPN dalam mata uang Rupiah

dibagi dengan Total Outstanding dalam mata uang Rupiah per masing-masing

cabang.

9. Laporan Movement CKPN (Charged atau Released) untuk setiap cabang

dalam mata uang rupiah. Charged berarti diperlukan tambahan sejumlah

biaya tertentu sebagai tambahan biaya pembentukan CKPN. Sedangkan

released berarti terdapat pengurangan biaya CKPN dibandingkan dengan

bulan sebelumnya.

10. Laporan Klasifikasi Loan Impairment dan Pembiayaan berdasarkan

Segmentasi dan Laporan Individual Impairment. Laporan Individual

Impairment berisi informasi daftar customer number yang sudah di daftarkan

dengan flag individual impairment.

Dari rangkaian masalah dan alternatif solusi tersebut, maka penulis tertarik untuk

menjawab pertanyaan penelitian

1. Bagaimana pengembangan datamart dalam perhitungan dan monitoring

penyisihan Cadangan Kerugian Penurunan Nilai(CKPN) sesuai dengan

Pernyataan Standar Akuntansi Keuangan (PSAK) 50/55 pada portfolio

pembiayaan di Bank ‘X’ ?

2. Bagaimana penerapan OLAP sehingga dapat membantu pengguna dan

eksekutif dalam mempersiapkan laporan, monitoring dan menganalisa

mengenai konsentrasi risiko pembiayaan terkait besarnya penyisihan

cadangan kerugian penurunan nilai (CKPN) dalam portfolio pembiayaan di

Bank ‘X’ setiap periode?


7


1.3 Tujuan dan Manfaat Penelitian

Adapun tujuan penelitian ini adalah:

1. Perancangan dan penerapan data mart untuk divisi Manajemen Risiko dan

Divisi Akuntansi dan Keuangan pada Bank ‘X’, mengenai penerapan PSAK

50/55 dalam konteks perhitungan CKPN untuk kepentingan Central Bank dan

Internal Management dapat tersedia secara cepat dan tepat waktu.

2. Penerapan teknologi OLAP untuk membantu menyediakan informasi berupa

laporan cadangan kerugian penurunan nilai sesuai dengan aturan PSAK 50/55

dan analisa untuk tujuan pengambilan keputusan.

Manfaat yang diperoleh dari penelitian ini adalah:

1. Perusahaan dapat memperoleh laporan yang dibutuhkan sesuai dengan

ketentuan regulator baik itu Bank Indonesia dan Ikatan Akuntan Indonesia

secara cepat dalam regular basis.

2. Informasi dapat ditampilkan ke dalam sebuah laporan yang sesuai dengan

keinginan para pihak terkait termasuk pihak eksekutif, sehingga dapat

membantu dalam pengambilan keputusan dan pelaporan. Informasi dapat

dilihat dari berbagai sudut pandang (perspektif) yang berbeda. Laporan dapat

dimodifikasi dan dibuat spesifik oleh pengguna dan disimpan sebagai

informasi personal.

3. Mempermudah manajemen dalam menganilisis perkembangan kualitas aktiva

kredit pada Bank X.

1.4 Ruang Lingkup Penelitian

Penelitian ini melibatkan berbagai disiplin ilmu, yang diantaranya adalah Basis

Data, statistika, datamart, Akuntansi dan Manajemen Risiko Perbankan. Dalam

penelitian ini batasan dan ruang lingkup yang diambil adalah

1. Proses dan aturan bisnis dari Bank X terkait implementasi Pernyataan Standar

Akuntansi Keuangan (PSAK) 50/55 untuk penyisihan cadangan kerugian

penurunan nilai (CKPN) pada Bank ‘X’.

2. Sumber data berasal dari masing-masing sumber sistem yang terdapat pada

Bank ‘X’.


8


3. Aplikasi yang digunakan untuk proses pembuatan data mart menggunakan

software Microsoft Business Intelligence Studio, Cognos Insight, dan

Database Microsoft SQL Server Database 2012.

1.5 Sistematika Penulisan

Untuk memberikan gambaran yang jelas dan sistematis mengenai isi penelitian

karya akhir ini, maka penelitian ini dibagi menjadi enam bab, dan disusun dengan

sistematika sebagai berikut:

BAB I PENDAHULUAN

Bab pertama berisi latar belakang pengambilan topik, permasalahan penelitian,

pertanyaan penelitian, tujuan dan manfaat penelitian, ruang lingkup penelitian

serta sistematika penulisan yang digunakan.

BAB II TINJAUAN PUSTAKA

Bab kedua berisi teori-teori mengenai datamart, arsitektur datamart. Metodologi

perancangan datamartmenurut Kimball, prosesETL, OLAP, serta Pedoman

Akuntansi Perbankan Indonesia mengenai PSAK 50/55.

BAB III METODOLOGI PENELITIAN

Bab ketiga berisi tahapan melakukan penelitian dan metodologi yang digunakan

pada penelitian ini.

BAB IV ANALISA, PERANCANGAN, DAN IMPLEMENTASI DATAMART

PSAK50/55

Bab ini akan menjelaskan mengenai implementasi datamart PSAK 50/55 dalam

rangka pelaporan dan monitoring penyisihan cadangan kerugian penurunan nilai

(CKPN) untuk portfolio pembiayaan Bank X. Pemaparan dimulai dari identifikasi

kebutuhan laporan, kebutuhan informasi dan proses bisnis, perancangan arsitektur

datawarehouse, perancangan permodelan datamart berdasarkan Metode Kimball

dengan 9 langkah yang terdiri dari pemilihan proses, pemilihan grain, identifikasi

dan penyesuaian dimensi, pemilihan fakta, penentuan data pre-kalkulasi dari tabel


9


fakta, melengkapi tabel dimensi, pemilihan durasi dari basis data, melacak

perubahan dimensi secara perlahan, penentuan prioritas dan mode dari query dan

pemrosesan ETL

BAB V IMPLEMENTASI OLAP

Berisi mengenai informasi yang disediakan oleh datamart dimana informasi

tersebut digunakan dalam menghasilkan laporan yang terkait dengan Pembiayaan

dan CKPN menurut PSAK 50/55 dengan visualisasi dari OLAP

BAB VI KESIMPULAN DAN SARAN

Bab terakhir ini memuat kesimpulan yang merupakan evaluasi dari seluruh

kegiatan dalam penelitian ini serta saran untuk pengembangan lebih lanjut.



BAB 2

TINJAUAN PUSTAKA

2.1 Datawarehouse dan Datamart

Pada bagian ini dijelaskan mengenai pengertian mengenai data warehouse dan

datamart, pemrosesan ETL, keuntungan penggunaan datamart dan isu-isu dalam

penggunaan datamart

2.1.1 Pengertian Data warehouse dan Datamart

Data warehouse didefinisikan sebagai sekumpulan data yang berorientasi subyek,

terintegrasi, berasal dari jangka waktu yang bervariasi dan cenderung permanen,

yang digunakan untuk mendukung proses pengambilan keputusan bagi pihak

manajemen sebuah organisasi (Connoly & Begg, 2005). Dan biasanya menyimpan

data histori dan data sekarang, dimana tujuan akhirnya adalah untuk mendapatkan

informasi yang dapat digunakan untuk analisa ke depan.

Data warehouse adalah sebuah sistem yang melakukan ekstraksi, clean, conforms,

dan memberikan sumber data ke dalam menyimpan data dimensi dan kemudian

mendukung dan menerapkan query dan analisis untuk tujuan pengambilan

keputusan. Dalam data warehouse, data disimpan dalam bentuk yang dapat

mendukung pengambilan keputusan dan analisis yang disebut sebagai Online

Analytical Processing Systems (OLAP).

Sedangkan Data mart adalah bagian (subset) dari data warehouse yang

mendukung kebutuhan informasi dari departemen tertentu atau fungsi dari bisnis

dalam perusahaan (Connolly & Begg, 2005). Adapun beberapa karakteristik yang

membedakan data warehouse dengan datamart, datamart merupakan spesifik

bisnis atau unit tertentu, subyek pengguna dari datamart biasanya departemental,

dan sifatnya desentralisasi.

Sistem OLAP berbeda dari sistem OLTP (Online Transactional Processing)

tradisional, atau yang dikenal sebagai sistem pengolahan transaksional secara


11


online. Sistem OLTP sangat dinormalisasi data model agar kinerja query lebih

cepat, tetapi dalam OLAP data model didasarkan pada denormalization untuk

membuat data agregasi yang digunakan dalam analisis dan pengambilan

keputusan untuk bisnis. Gambar 2.1 menjelaskan 4 komponen dari data

warehouse menurut Ralph Kimball.

Gambar 2.1 Datawarehouse Model

(Sumber : Kimball, 2002)

1. Operational Source Systems: sistem operasional yang digunakan untuk

transaksional bisnis sehari-hari. Isi dari sumber data dari operational sistem

tidak dalam termasuk ke dalam data warehouse karena data warehouse tidak

memiliki kontrol atas data transaksi operasional.

2. Data Staging Area: Data staging area di data warehouse diproses melalui

proses ETL menggunakan input dari ekstrak source system. Ekstraksi adalah

langkah pertama dalam proses penyediaan data dari sistem sumber ke data

warehouse. Ekstrak berarti membaca dan memahami sumber data dan

menyalin data yang diperlukan untuk data warehouse ke staging area. Setelah

data diekstrak ke staging area, dilakukan proses transformasi data, seperti

pembersihan data (standarisasi format data, validasi karakter khusus dalam

data, eliminsasi data yang null atau tidak lengkap), melakukan konversi tipe

data, validasi integritas referensi data, penggabungan data dan perhitungan

dengan melakukan agregasi. Transformasi ini diperlukan untuk memuat data

ke dalam data warehouse presentation area.


12


3. Data Presentation Area: adalah tempat dimana data tersebut diorganisasi,

disimpan dan dibuat untuk tujuan direct query oleh pengguna akhir, reporting

dan kebutuhan analitical.

4. Data Access Tools: Alat merujuk pada berbagai pilihan bahwa pengguna

bisnis dapat memanfaatkan untuk menganalisis data untuk analisis

pengambilan keputusan. Menurut definisi, semua alat akses data query data di

daerah presentasi data warehouse itu. Pengaksesan data dapat sesederhana

sebagai alat query ad hoc atau sekompleks data mining.

5. Metadata: Salah satu komponen yang paling penting dari data warehouse

adalah metadata. Metadata adalah semua informasi dalam lingkungan data

warehouse yang mana bukan merupakan data aktual itu sendiri. Atau dapat

dikatakan sebagai informasi tentang data. Cakupan metadata mulai dari

source system sampai dengan pada staging area. Metadata digunakan sebagai

sumber informasi untuk memfasilitasi proses transformasi dan proses loading,

termasuk staging file dan layout tabel, transformasi dan pembersihan, tabel

dimensi dan fact table, definisi agregasi, dan penjadwalan pelaksanaan ETL

dan menghasilkan file log. Bahkan kode pemrograman yang dibuat secara

kustom di ETL merupakan bagian dari metadata. Data staging area metadata

juga digunakan oleh data presentation dan data access tools untuk kontrol

proses dan dapat digunakan untuk logic tertentu tergantung dari kebutuhan

informasi yang dihasilkan. Tujuan akhir adalah membuat catalog,

mengintegrasikan dan memanfaatkannya sebagai dokumentasi library.

2.1.2 Extraction Transformation Loading (ETL)

ETL merupakan proses mengambil data aplikasi yang dibutuhkan dan

mengintegrasikannya ke dalam data warehouse. ETL adalah proses

menyiapkan data yang meliputi pengambilan data yang dibutuhkan,

pengubahan dan pengintegrasian data, serta pemuatan data dari sumber data ke

dalam data warehouse. (Inmon, 2005)

Di dalam jurnal yang ditulis oleh (Steinacher, 2000), proses ETL dibagi menjadi 3

bagian, yaitu:


13


1. Data extraction; Untuk memulai proses ETL, programmer akan

menjalankan rutin extraction untuk membaca record dari database

sumber dan membuat data pada record dapat dipakai untuk proses

transformasi.

2. Data transformation; Setelah melakukan proses extraction, data kemudian

ditransformasikan ke dalam bentuk yang cocok dengan lingkungan data

warehouse. Terdapat beberapa teknik tranformasi yang sering dilakukan,

yaitu aggregation, value translation, field derivation, dan cleansing.

Sebelum melakukan loading ke data warehouse, biasanya programmer

akan melakukan aggregate data terlebih dahulu. Aggregation akan

menggantikan sejumlah record detail dengan beberapa baris record

ringkasan. Sebagai contoh, andaikan data penjualan dalam setahun

disimpan dalam beberapa ribu record dalam database yang sudah

dinormalisasi. Melalui aggregation, data tersebut ditransformasi menjadi data

ringkas yang akan disimpanpada data warehouse penjualan. Value

translation merupakan salah satu teknik dalam transformasi data.

Database operasional menyimpan kode informasi untuk membatasi

redudansi data dan merupakan syarat penyimpanan. Sebagai contoh, kode

barang ditulis di dalam file faktur karena panjangnya yang pendek,

daripada menulis deskripsi produk dalam faktur. Karena data warehouse

mengandung informasi ringkasan dan dirancang untuk kemudahan

penggunaan, programmer biasanya mengganti kode tersebut dengan

deskripsi yang lebih jelas. Inilah yang disebut sebagai value translation. Field

derivation merupakan teknik ketiga dalam mentransformasikan data.

Melalui field derivation, informasi baru diciptakan untuk pengguna.

Sebagai contoh, andaikan database operasional mengandung kolom untuk

jumlah penjualan dan harga per unit. Daripada membuat pengguna

menghitung penghasilan, programmer dapat membuat kolom penghasilan

selama proses transformasi. Produk-produk ETL telah memungkinkan

programmer untuk menggunakan operasi matematika, fungsi statistik,

manipulasi string, date arithmetic, dan logika kondisional untuk

menurunkan kolom baru. Teknik transformasi yang keempat, cleansing,


14


mempunyai banyak kegunaan. Programmer bergantung pada algoritma

cleansing untuk menjaga agar data yang tidak akurat tidak masuk ke dalam

sistem. Sebagai contoh, cleansing biasanya memastikan bahwa kolom numeric

mengandung data angka. Cleansing dapat juga digunakan dalam kasus

dimana satu nilai unik direpresentasikan dalam banyak cara di database.

Sebagai contoh, IBM dapat digambarkan sebagai IBM Co. atau

International Businesss Machines, dan lain sebagainya. Selama proses

cleansing, versi-versi lain dari elemen data yang sama diganti dengan

nilai tunggal. Tipe-tipe transformasi yang biasa di implementasikan pada

data warehouse adalah sebagai berikut :

Format-Changes, dimana setiap data field dari sistem operasional

disimpan dalam format dan tipe data yang berbeda. Individual data ini

akan di modifikasi selama proses transformasi ke dalam format yang di

standarisasi.

De-duplication, record dari beberapa sumber dibandingkan untuk

mengidentifikasi adanya duplikasi berdasarkan nilai dari suatu field.

Data yang terduplikasi bisa di merge menjadi suatu single record.

Record yang potensial mengalami duplikasi akan dipisahkan dalam suatu

tempat untuk di pilah secara manual.

Splitting up fields, data dari source system sangat mungkin untuk di

pisahkan dalam satu atau beberapa field dalam data warehouse. Hal

yang sering terjadi adalah pemisahan data informasi customer yang

terdiri dari satu field dipisahkan menjadi beberapa field di data

warehouse seperti nama jalan, nama gedung, kota, kode pos dan

sebagainya.

Integrating fields, kebalikan dari splitting up fields dimana dua buah field

atau lebih akan di integrasikan dalam satu field.

Replacement of values, jika data dalam system operasional memliki

makna yang kurang informatf bagi pengguna warehouse, akan

ditransformasikan kedalam bentuk yang lebih sesuai.

Derived values, field yang dihasilkan dari formulasi fungsi agregasi.

Dengan melakukan penghitungan sebelum dimasukkan ke dalam data


15


warehouse maka kemungkinan kesalahan yang akan dilakukan oleh

pengguna warehouse akan berkurang. Sebagai contoh field balance, ratio

dan sebagainya

Aggregate, field yang diagregasi secara atomik juga dapat dilakukan

sebelum dimasukkan ke dalam data warehouse.

3. Data loading; Setelah data ditransformasikan, programmer menggunakan

prosedur load untuk menulis data tersebut ke dalam database yang

menjadi target. Selama tahap ini, kita harus menentukan apakah akan

menyebarkan data secara berkala atau terus-menerus. Penambahan terjadi

secara teratur, seperti harian, mingguan, atau bulanan. Pendekatan ini

merekam kondisi sistem operasional pada saat-saat spesifik. Jika

pengguna menginginkan informasi terkini, continuous propagation dapat

memuat data ke dalam database target pada basis waktu real-time. Kita

bisa mengkategorikan data loading berdasarkan metode yang dipakai

untuk mereplikasi data. Dalam replikasi push, aplikasi sumber

“mendorong‟ data yang telah ditransformasi ke aplikasi target. Dalam

replikasi pull, aplikasi target “menarik‟ data yang diperlukan olehnya,

seperti ketika pengguna menjalankan sebuah query. Kita juga bisa merancang

prosedur load yang menggunakan proses pull dan push. Pada pendekatan tipe

ini, aplikasi sumber biasanya mendorong data ke staging database, dimana

data tersebut akan ditransformasi dan kemudian ditarik ke dalam aplikasi

target ketika diperlukan saja. Pendekatan tipe ini memerlukan ruang disk

yang lebih besar, tapi dapat meningkatkan performa.

2.1.3 Keuntungan Data Warehouse

Data warehouse dapat memberikan keuntungan kepada perusahaan seperti

(Connoly & Begg, 2005):

1. Potensi pengembalian yang besar dari investasi (potential high returns on

investment). Sebuah perusahaan harus mengeluarkan sejumlah besar dana

untuk memastikan keberhasilan penerapan data warehouse dan biayanya

dapat bervariasi tergantung dari solusi teknis yang diberikan. Potensi

pengembalian dari investai ke dalam data warehouse sangat besar.


16


Tergantung dari bagaimana para pengambil keputusan memakai data

warehouse dalam proses pengambilan keputusan.

2. Keuntungan kompetitif (competitive advantage). Pengembalian yang besar

atas investasi perusahaan merupakan hasil dari keuntungan kompetitif

yang didapatkan dari penggunaan teknologi ini. Keuntungan kompetitif

dapat diperoleh dengan memfasilitasi para pengambil keputusan

mengakses data yang dapat memperlihatkan apa yang sebelumnya tidak

dapat dilihat karena keterbatasan teknologi, seperti pelanggan, tren, dan

permintaan.

3. Meningkatkan produktivitas dari para pengambil keputusan (increased

productivity of corporate decision-makers). Data warehouse dapat

meningkatkan produktivitas dari para pengambil keputusan dengan

membuat sebuah database terpadu dari data-data yang konsisten,

berorientasi subjek, dan bersifat historis. Data warehouse menyatukan data

dari berbagai sistem dan dijadikan data yang lebih konsisten. Dengan

mengubah data menjadi informasi yang berguna, data warehouse

memungkinkan para pengambil keputusan untuk melakukan analisis yang

lebih nyata, akurat, dan konsisten.

2.1.4 Isu Data warehouse

Beberapa faktor yang dapat dikaitkan dengan masalah kualitas informasi, berikut

ini adalah penyebab utama dari kesalahan informasi dalam data warehouse

1. Perubahan pada sumber data.

Perubahan dalam sumber data menyebabkan perubahan code pada proses

ETL. Contohnya : proses ETL pada risiko kredit pada data dalam lembaga

keuangan tertentu memiliki sekitar 25 kesalahan setiap kuartal. Meskipun

telah melampaui quality assurance tetap saja selalu ada ruang untuk

kesalahan. Daftar berikut menguraikan jenis potensi kesalahan yang dapat

terjadi karena perubahan dalam proses ETL:

Logika pada ekstraksi tidak mencakup data tertentu yang belum ditest.

Logika transformasi memungkinkan melakukan agregasi 2 tipe data yang

berbeda (contoh: Pinjaman Mobil, Pinjaman Kapal) ke dalam satu


17


kategori, yaitu kategori pinjaman mobil. Dalam beberapa kasus, logika

transformasi dapat mengecualikan beberapa jenis data yang tidak relevan,

sehingga catatan lengkap di data warehouse.

Isu-isu serupa juga sering terjadi pada proses loading.

2. Kegagalan proses. Saat pemrosesan mungkin saja gagal, karena kesalahan

sistem atau kesalahan transformasi, sehingga loading data yang tidak lengkap.

Kesalahan transformasi juga mungkin disebabkan karena format sumber data

atau format tujuan transformasi yang salah.

3. Perubahan atau update pada data referensi. Data referensi outdated, tidak

lengkap atau salah akan menyebabkan kesalahan dalam informasi data

warehouse. Misalnya, kesalahan dalam parameter tabel komisi tingkat

penjualan dapat mengakibatkan perhitungan yang salah tentang jumlah komisi

yang diterima oleh masing-masing agen.

4. Isu kualitas data dengan sistem sumber. Data ini mungkin tidak lengkap atau

tidak konsisten. Sebagai contoh, catatan pelanggan dalam source system

mungkin memiliki kode pos hilang. Sebuah sistem sumber yang sama

berkaitan dengan penjualan dapat menggunakan singkatan dari nama-nama

produk dalam database-nya. Ketidaklengkapan dan inkonsistensi dalam data

sistem sumber akan menyebabkan masalah kualitas dalam data warehouse.

Adapun yang merupakan contoh kontrol yang dapat diterapkan untuk setiap

informasi pada data warehouse antara lain :

- Validasi antara source system, data warehouse, datamart, dan sistem target

lainnya.

- Validasi secara independen pada masing-masing environment, yaitu

environment tempat pemrosesan ETL, environment yang menjadi tempat

sumber data dan environment tujuan load.

- Penerapan kontrol pada format data dari semua sumber data dan tabel tujuan

transformasi.

- Membuat laporan exceptions untuk setiap kali pemrosesan data, yang berisi

informasi status, jumlah data, dan waktu dari setiap hasil proses ETL termasuk

audit trail dari setiap hasil pemrosesan.


18


Biasanya pendekatan yang dilakukan dalam rangka kontrol pada data warehouse

antra lain melakukan manual balancing, tracking dan rekonsiliasi untuk

memastikan akurasi dari data, sesuai dengan kebutuhan melakukan ad hoc query

dan pelaporan untuk mendukung kegiatan audit, dimana secara tidak langsung

merupakan bagian dari solusi regulatory reporting. Dan secara periodik

melakukan pemeriksaan dan mendiagnosa serta memperbaiki problem yang ada.

Sedangkan yang terkait dengan isu dari perancangan data warehouse, (Yao, 2003)

memberikan rangkuman yang komprehensif mengenai isu dari perancangan ini

meliputi:

- Granularity : Level dari detail atau rangkuma setiap unit data.

- Partitioning : memisahkan data ke dalam physical unit yang berbeda.

- Data : Tiga tipe data yaitu raw data , aggregated data dan metadata

- Data sources : Sumber dari sistem operasional tempat sumber data yang akan

di populasi ke data warehouse.

- ETL process : proses antara source system dan data warehouse, termasuk

proses didalam data warehouse itu sendiri.

- User access : antar muka dan alat-alat analisis yang dibuat dapat tersedia

untuk pengguna

2.2 Metodologi Perancangan Data Warehouse/Datamart

Menurut Kimball terdapat sembilan langkah dalam merancang database untuk

data warehouse (Kimbal & Ross, 2002) yaitu :

Langkah 1: Memilih proses

Proses ini merujuk pada subjek data warehouse tertentu. Data warehouse

yang dibangun pertama kali haruslah data warehouse yang dapat dikerjakan

dan selesai tepat waktu, biaya yang cukup, dan menjawab pertanyaan bisnis

paling penting. Contoh pemilihan proses adalah yang berkaitan dengan proses

penjualan.


19


Langkah 2: Memilih grain

Memilih grain berarti kita memutuskan secara tepat apa yang

direpresentasikan oleh record pada tabel fakta. Sebagai contoh, entitas

PropertySale merepresentasikan fakta tentang tiap-tiap penjualan properti dan

menjadi tabel fakta dari star schema penjualan properti. Oleh karena itu,

grain dari tabel fakta PropertySale adalah setiap record penjualan properti.

Ketika kita sudah memilih grain dari tabel fakta, maka kita bisa

mengidentifikasikan dimensi-dimensi dari tabel fakta.

Langkah 3: Identifikasi dan membuat dimensi yang sesuai

Dimensi mengatur konteks untuk mengajukan pertanyaan tentang fakta-fakta

dalam tabel fakta. Dimensi yang dirancang dengan baik membuat datamart

lebih mudah dimengerti dan digunakan. Dimensi yang tidak lengkap dan kurang

akan menurunkan manfaat dari sebuah datamart bagi perusahaan. Jika terdapat

dimensi yang muncul dalam dua datamart, mereka harus merupakan dimensi

yang persis sama, atau salah satu harus merupakan subset matematis dari

yang lain. Hanya dengan cara ini, dua datamart dapat saling berbagi satu

atau lebih dimensi pada aplikasi yang sama. Ketika sebuah dimensi

digunakan pada lebih dari satu data mart, maka dimensi itu disebut sedang

disesuaikan. Kalau dimensi tersebut tidak disinkronisasi, maka keseluruhan data

warehouse akan gagal karena kedua datamart tidak akan dapat digunakan secara

bersama-sama.

Langkah 4: Memilih fakta

Grain pada tabel fakta menentukan fakta mana yang dapat digunakan dalam

datamart. Semua fakta harus diekspresikan pada tingkatan yang telah

dinyatakan oleh grain. Dengan kata lain, kalau grain dari tabel fakta adalah

setiap record pada penjualan properti, maka semua fakta numerik harus merujuk

pada penjualan jenis ini. Dan juga, fakta harus berupa numerik dan hasil

penjumlahan.


20


Langkah 5: Menentukan data pre-kalkulasi dari tabel fakta

Ketika fakta telah dipilih, maka masing-masing fakta tersebut harus diperiksa

ulang untuk menentukan apakah ada kemungkinan untuk menggunakan pre-

kalkulasi. Contoh umum akan kebutuhan menyimpan pre-kalkulasi terjadi

ketika terdapat fakta yang terdiri dari pernyataan laba dan rugi. Situasi ini akan

sering terjadi ketika tabel fakta berdasarkan penjualan atau invoice.

Langkah 6: Melengkapi tabel dimensi

Pada langkah ini, kita melengkapi tabel dimensi dengan menambahkan

keterangan ke dalamnya. Deskripsi ini harus intuitif dan mudah dimengerti

oleh pengguna.

Langkah 7: Memilih durasi dari basis data

Kita harus menentukan seberapa jauh durasi waktu yang ditampung di dalam

tabel fakta. Untuk perusahaan seperti perusahaan asuransi, mengharuskan

untuk menyimpan data sampai 5 tahun atau lebih. Tabel fakta yang sangat

besar menimbulkan setidaknya dua masalah signifikan pada data warehouse.

Pertama, semakin tua suatu data, maka akan ada masalah dalam membaca dan

menginterpretasikan file tua tersebut. Kedua, wajib untuk menggunakan versi

lama dari dimensi penting, bukan versi yang baru. Ini dikenal sebagai

masalah pada slowly changing dimension.

Langkah 8: Melacak dimensi yang berubah secara perlahan

Ada tiga tipe dimensi yang berubah secara perlahan (slowly changing dimension),

yaitu: Tipe 0, yaitu dimensi yang tidak pernah mengalami perubahan, contohnya

dimensi waktu. Tipe 1, yaitu perubahan dimensi menyebabkan data lama di-

overwrite. Tipe 2, yaitu perubahan dimensi menyebabkan pembentukan record

baru. Tipe 3 yaitu perubahan dimensi menyebabkan pembuatan atribut

alternatif sehingga nilai yang lama dan nilai yang baru dapat diakses secara

bersama pada dimensi yang sama.


21


Langkah 9: Menentukan prioritas dan mode dari query

Pada langkah ini, kita mempertimbangkan permasalahan desain fisik.

Permasalahan desain fisik paling kritis yang mempengaruhi persepsi

pengguna terhadap data mart adalah urutan fisik dari tabel fakta pada disk dan

kehadiran ringkasan atau aggregation yang telah disimpan.

2.3 Arsitektur Datamart

Gambar 2.2 Arsitektur Data warehouse

(Sumber : Conolly & Begg, 2005)

Gambar 2.2 mengenai arsitektur data warehouse oleh Connoly dan Begg

dijelaskan sebagai berikut:

Operasional data: Sumber data dari data warehouse dapat diambil langsung

dari mainframe, basis data relasional seperti Oracle, Ms SQL Server dan

sebagainya. Selain itu dapat melalui Operational Data Source (ODS). ODS

menampung data yang diekstrak dari sistem utama atau sumber-sumber data

yang ada dan kemudian data hasil ekstraksi tersebut disesuaikan.


22


Load manager : Load Manager juga disebut komponen front-end yang

bertugas melakukan seluruh operasi yang berhubungan dengan ekstrasi dan

me-load data ke data warehouse.

Warehouse manager: Warehouse manager melakukan seluruh operasi-

operasi yang berhubungan dengan kegiatan manajemen data didalam data

warehouse. Operasi-operasi tersebut meliputi: analisis terhadap data untuk

memastikan konsistensi, transformasi dan penggabungan sumber data dari

tempat penyimpanan sementara menjadi tabel-tabel data warehouse,

penciptaan indeks-indeks dan view berdasarkan tabel-tabel dasar, melakukan

denormalisas dan agregasi jika diperlukan dan backup atau pengarsipan data.

Query Manager : Query manager juga disebut komponen back-end,

melakukan operasi-operasi yang berhubungan dengan manajemen user

queries. Operasi-operasi yang dilakukan oleh komponen itu termasuk query

kepada tabel-tabel yang tepat dan menjadwalkan eksekusi dari query tersebut.

Detailed data : Pada rancangan data warehouse, detailed data menyimpan

semua detail dari data di dalam skema basis data. Biasanya detailed data

tidak disimpan secara online melainkan dibuat dengan melakukan agregasi

data. Tetapi pada dasarnya detailed data ditambahkan ke data warehouse

untuk melengkapi data agregasi. Detailed data dibagi menjadi dua yaitu:

current detailed data dan old detailed data.

Lightly and highly summarized data : Pada rancangan data warehouse, ligthly

and highly summarized data adalah tempat penyimpanan semua data

predefined lightly dan highly summarized yang dihasilkan oleh warehouse

manager. Tujuan dari ringkasan informasi ini adalah memercepat tanggapan

terhadap permintaan user. Ringkasan data dilakukan update terus-menerus

seiring dengan bertambahnya jumlah data dalam data warehouse.

Archieve/backup data : Pada rancangan data warehouse, archieve/backup

data digunakan sebagai tempat penyimpanan detailed data dan data yang

telah diringkas. Data yang telah diringkas dan disimpan akan ditransfer ke

media penyimpanan seperti magnetic tape danoptical disk.


23


Metadata : Pada rancangan data warehouse, metadata digunakan sebagai

tempat penyimpanan semua definisi keterangan mengenai data yang

digunakan diseluruh proses data warehouse.

End-user access tools (EUAT) : Prinsip atau tujuan utama dibangunnya data

warehouse adalah untuk menyediakan informasi bisnis kepada pengguna

untuk dapat melakukan pengambilan keputusan secara cepat dan tepat.

Pengguna ini berinteraksi dengan data warehouse melalui end-user access

tools.

2.4 Konsep Permodelan Data Warehouse

Konsep Permodelan data warehouse dibedakan menjadi beberapa pendekatan

perancangan termasuk penentuan perancangan dimensi yang digunakan.

2.4.1 Star Schema

Star schema adalah struktur logikal yang dibentuk dari sebuah tabel fakta yang

mengandung data fakta pada bagian tengah, dikelilingi oleh tabel-tabel

dimensi yang mengandung data referensi, dimana data tersebut dapat

didenormalisasi (Connoly & Begg, 2005). Star schema mengeksploitasi

karakteristik dari data faktual seperti fakta yang dihasilkan oleh peristiwa

yang muncul pada waktu yang lalu dan tidak berubah, tanpa memperhatikan

bagaimana mereka dianalisis. Penting untuk memperlakukan data fakta sebagai

data referensi yang bersifat read-only. Star schema dapat dipakai untuk

meningkatkan kecepatan performa kinerja query dengan melakukan

denormalisasi informasi referensi ke dalam tabel dimensi tunggal.

Denormalisasi dianjurkan ketika terdapat sejumlah entitas yang berhubungan

dengan tabel dimensi yang sering diakses. Gambar 2.3 merupakan contoh

perancangan star schema.


24


Gambar 2.3 Perancangan Star Schema

2.4.2 Snowflake Schema

Snowflake schema adalah variasi lain dari star schema dimana tabel dimensi tidak

berisi data yang didenormalisasi (Connoly & Begg, 2005). Pada snowflake

schema, sebuah tabel dimensi dapat mempunyai tabel dimensi lainnya.

Keuntungan yang didapat dengan menggunakan skema ini adalah penghematan

memory, tetapi waktu yang dibutuhkan untuk pemrosesan query menjadi lebih

lama. Gambar 2.contoh perancangan snowflake skema.


25


Gambar 2.4 Perancangan Skema Snow Flake

2.4.3 Schema Galaxy / Fact Constellation

Fact constellation schema adalah dimensional model yang didalamnya terdapat

lebih dari satu tabel fakta yang membagi satu atau lebih tabel dimension. Skema

ini lebih kompleks daripada star schema karena berisi berbagai tabel fakta. Dalam

skema fact constellation, satu dimensi tabel dapat digunakan di beberapa tabel

fakta sehingga desainnya lebih kompleks. Keuntungan dari skema fact

constellation adalah kemampuan untuk memodelkan bisnis lebih akurat

menggunakan beberapa tabel fakta dan dapat menghemat memori dan mengurangi

kesalahan yang mungkin terjadi. Skema Fact Constellation biasanya digunakan

dalam sebuah desain Enterprise Data Warehouse, sedangkan dua desain lainnya

(star skema dan snow flake skema) digunakan untuk membangun data warehouse

atau datamar tdengan skala yang lebih kecil yang spesifik untuk memenuhi

kebutuhan sebuah bagian/unit bisnis dari sebuah organisasi. Gambar 2.5 contoh

perancangan dengan skema fact constellation.


26


Gambar 2.5 Perancangan Skema Fact Constellation (Conolly & Begg, 2005)

2.4.4 Slowly Changing Dimension (SCD)

Slowly Changing Dimension (Kimball, 2008) adalah nama dari sebuah proses

pengelolaan data yang memuat data ke dalam tabel dimensi yang berisi data.

Untuk mengadopsi SCD, data harus berubah secara perlahan pada jadwal yang

tidak teratur, random dan variabel. Dalam suatu datamart, terdapat kebutuhan

untuk melacak perubahan dalam dimensi atribut dalam rangka pelaporan data

historis. Dengan kata lain, menerapkan salah satu jenis SCD harus memungkinkan

pengguna menetapkan nilai atribut dimensi yang tepat untuk tanggal tertentu.

Contoh dimensi seperti itu bisa: pelanggan, geografi, karyawan. Ada 6 jenis saat

ini metodologi SCD, yaitu Tipe 0, Tipe 1, Tipe 2, Tipe 3, Tipe 4, dan Tipe 6. Jenis

SCD paling umum dilakukan adalah Type 1, 2 dan 3.

Tipe 0 adalah tipe dari SCD yang tidak pernah mengalami perubahan data. Nilai-

nilai asli tetap berada di dimensi sewaktu tabel dimensi ini pertama kali dibuat.

Tipe 1 adalah type dari SCD yang mengupdate isi data yang lama dengan data

yang baru. SCD Tipe 1 adalah tipe perubahan dimensi yang mudah untuk di-

maintain, namun tidak ada data histori yang disimpan pada datawarehouse.

Tipe 2 adalah tipe dari SCD yang menambahkan satu record baru apabila

terdapat perubahan data, sehingga setiap kali ada perubahan data tersimpan dalam

data histori.


27


Tipe 3 adalah tipe dari SCD yang melakukan update perubahan data yang baru

pada kolom yang baru.

Tipe 4 menggunakan tabel histori, dengan memindahkan record lama yang

berubah pada tabel histori (archive) dan me-maintain record yang baru / terudpate

pada tabel yang current.

Tipe 6 SCD adalah metodologi hybrid tipe 1, 2 dan 3. Pada tipe ini kita miliki

dalam tabel dimensi kolom tambahan seperti:

current_type: untuk menjaga nilai saat ini dari atribut. Semua record histori

untuk diberikan item atribut memiliki nilai yang sama saat ini.

historical_type : untuk menjaga nilai histori atribut. Semua histori record

untuk diberikan item atribut bisa memiliki nilai yang berbeda.

start_date: untuk menjaga tanggal mulai 'tanggal efektif' histori atribut itu.

end_date: untuk menjaga tanggal akhir dari 'tanggal efektif' histori atribut itu.

current_flag: untuk menjaga informasi tentang catatan terbaru.

Contoh penerapan SCD Tipe-6 dapat dilihat pada Tabel 2.1

Tabel 2.1 Contoh penerapan SCD Type 6

Customer_

ID

Customer_N

ame

Current_T

ype

Historical_T

ype

Start_D

ate

End_D

ate

Current_F

lag

1 Cust_1 Corporate Retail 11-01-

2011

28-07-

2011 N

2 Cust_1 Corporate Other 29-07-

2011

17-05-

2012 N

3 Cust_1 Corporate Corporate 18-05-

2012

31-12-

9999 Y


28


2.5 Business Intelligence dan OLAP

Business Intelligence adalah seperangkat teori, metodologi, proses, arsitektur, dan

teknologi yang mengubah data mentah menjadi informasi yang bermakna dan

berguna untuk tujuan bisnis. BI dapat menangani sejumlah besar informasi untuk

membantu mengidentifikasi dan mengembangkan peluang baru. Memanfaatkan

peluang baru dan menerapkan strategi yang efektif dapat memberikan keuntungan

pasar kompetitif dan stabilitas jangka panjang.

Business Intelligence sebagai pendekatan baru bagi perusahaan yang

mengumpulkan, mengatur, dan menggunakan informasi. Dia percaya bahwa cara

lama telah berubah untuk merefleksikan teknologi yang baru dan masa kini,

karena perusahaan membutuhkan keputusan yang cepat (real-time) berdasarkan

data yang ada. Saat ini, dalam situasi bisnis yang berdaya saing tinggi, nilai dari

sistem informasi strategis sangat terlihat. Tingginya tingkat adopsi dan investasi

pada software BI dan pelayanannya membuktikan bahwa sistem ini sangat

dibutuhkan dalam mendukung pengambilan keputusan bagi perusahaan dalam

kondisi pasar saat ini (Turban, 2007).

Turban mengumpamakan Business Intelligence sebagai sebuah payung, yang

melingkupi arsitektur, tools, database, aplikasi dan metodologi. Turban juga

mengatakan bahwa tujuan utama dari Business Intelligence adalah memungkinkan

akses interaktif dan eksploitasi terhadap data, serta menyediakan data tersebut

untuk digunakan oleh para manajer dan para analis. (Turban et al., 2007)

Sumber data yang berbeda yang telah dikumpulkan dan disimpan di perusahaan

harus diekstrak dari berbagai sumber, kemudian diubah menjadi format yang

konsisten dan dimuat serta disimpan dalam data warehouse dan dianalisa untuk

mendapatkan keputusan yang tepat, sehingga menjadi efisien bagi perusahaan.

Dengan ini perusahaan dapat membuat keputusan bisnis yang lebih baik dan lebih

cepat dibandingkan dengan para pesaingnya.


29


Business intelligence report lahir untuk menjawab tantangan yang tidak bisa

dipenuhi oleh standard pelaporan, yaitu yang berkaitan dengan empat hal yaitu

accessibility, timeliness, format, data integrity.

Business Intelligence memiliki sambungan langsung ke Data warehouse sehingga

accessibility dan timeliness menjadikan hal yang biasa dilakukan. User selalu

mendapatkan akses terhadap informasi yang dibutuhkan (accessibility) secara

cepat (timeliness).

Business Intelligence memberikan kebebasan kepada pengguna untuk

mendefinisikan format laporan sesukanya, sedangkan Data Integrity dipenuhi oleh

Data warehouse di mana BI ini dijalankan. Salah satu yang menjadi kelebihan

dari Business Intelligence adalah memanjakan pengguna dengan struktur data

yang memudahkan pembuatan laporan secara self-service dalam bentuk dimensi

dan measures. Dengan mengkombinasikan measures dan dimensi yang tepat,

pengguna mendapatkan laporan yang diinginkan. Selanjutnya diajuga dapat

menyajikannya dalam bentuk tabel atau dalam berbagai bentuk grafik yang dapat

dipilih. Setelah laporan disajikan, pengguna diberi fasilitas untuk menyimpan

tampilan laporan tersebut dalam bentuk excel, xml, pdf, jpeg, dan lain-lain sesuai

kebutuhan.

2.5.1 On-Line Analytical Processing (OLAP)

On-Line Analytical Processing (OLAP) merupakan suatu jenis pemrosesan yang

dapat memanipulasi dan menganalisa data bervolume besar dari berbagai

perspektif (multidimensi). OLAP seringkali disebut analisis data multidimensi

Kegunaan utama OLAP adalah fitur interaktifnya untuk membantu pimpinan

organisasi melihat data dari berbagai perspektif. OLAP dapat membantu

pengguna untuk menganalisis data pada sebuah data warehouse dengan berbagai

tampilan data, dan representasi grafik yang dinamis. Dalam tampilan tersebut

dimensi-dimensi data berbeda menunjukkan karakteristik bisnis yang berbeda

pula. OLAP sangat membantu untuk melihat data dimensional dari berbagai sudut


30


pandang. Maka dari itu OLAP dapat membantu end-user menarik kesimpulan dan

keputusan.

2.5.2 Tipe-tipe operasi OLAP

Fitur-fitur dibawah ini merupakan fitur dari pemanfaatan OLAP (Han & Kamber,

2004)

Roll-up

Operasi ini melakukan agregasi pada kubus data dengan cara menaikkan tingkat

suatu hirarki konsep atau mengurangi dimensi. Misalkan pada kubus datadari

kelompok kota di-roll up menjadi kelompok propinsi atau negara. Contoh lainnya

kubus data menampilkan agregasi total penjualan berdasarkan lokasi dan waktu,

roll up mereduksi dimensi dapat dilakukan dengan menurunkan tingkat suatu

hirarki konsep atau menambahkan dimensi menghilangkan waktu sehingga hanya

menampilkan agregasitotal penjualan berdasarkan lokasi.

Drill-down

Drill-down adalah kebalikan dari rollup. Operasi ini mempresentasikan data

menjadi lebih detil. Drill-down dilakukan dengan cara menurunkan tingkat suatu

hirarki konsep atau menambahkan dimensi. Misalkan dari kelompok tahun di drill

down menjadi kelompok triwulan, bulan, atau hari.

Slice dan dice

Operasi slice and dice adalah operasi untuk melihat data sebagai visualisasi dari

cube. Dengan slice and dice, pengguna dapat melihat suatu data dengan berbagai

perspektif. Operasi slice yaitu melakukan pemilihan atau pemotongan terhadap

satu dimensi dari data cube yang ada sehingga menghasilkan bagian sub cube.

Operasi dice mendefinisikan sub cube dengan melakukan pemilihan dua atau

lebih dimensi dari suatu cube.


31


Pivot (rotate)

Pivot adalah operasi visualisasi dengan memutar koordinat data pada tampilan

yang bertujuan untuk menyediakan presentasi atau perspektif alternatif dari data.

2.6 Penelitian Sebelumnya

Pada bagian ini dijelaskan mengenai penelitian sebelumnya yang berkaitan

dengan perancangan datawarehouse atau perancangan datamart, perancangan

arsitektur datawarehouse, pemrosesan dan permodelan ETL serta implementasi

business intelligence.

Penelitian oleh (Indra, 2011) mengenai perancangan dan penerapan data

warehouse dan business intelligence untuk efisiensi pelaporan menjelaskan nilai

tambah bagi organisasi dalam penyusunan laporan yang lebih cepat dan efisien.

Metodologi yang digunakan dalam penelitian ini terdiri dari identifikasi

kebutuhan informasi, pengumpulan data, perancangan data warehouse dan

perancangan dashboard. Perancangan data warehouse pada penelitian ini

mengikuti proses: cleansing dan ETL, perancangan tabel dimensi dan tabel fakta,

perancangan cube dan OLAP dan perancangan dashboard dengan visualisasi data

dengan solusi Microsoft business intelligence.

Penelitian oleh (Ariyachandra dan Hugh J. Watson, Business Intelligence Journal

Volume-11) mengenai arsitektur datawarehouse yang terbaik, alternatif arsitektur

yang diteliti pada penelitian ini dibedakan menjadi 5 arsitektur, yang terdiri dari

(1) independent datamart, (2) datamart bus architecture dengan keterkaitan

hubungan dengan dimensional data mart, (3) hub and-spoke, (4) centralized data

warehouse (no dependent datamart), dan (5) federated. Penilaian yang dilakukan

dengan mengkategorisasikan data warehouse yang didasarkan atas beberapa

aspek yang terdiri dari information quality (information accuracy, completeness,

and consistency), system quality (flexibility, scalability,integration), dampak

terhadap individual dan dampak terhadap organisasi terhadap masing-masing

arsitektur. Hasilnya bus architecture dan arsitektur hub and spoke memperoleh

penilaian yang mendekati.


32


Penelitian oleh (Nitin Anand, 2013 - 4th ICCCNT 2013) mengenai Modeling dan

optimasi proses ETL pada data warehouse, dimana siklus dari pengembangan

data warehouse dan proses ETL didalamnya dimulai dari Reverse Engineering

dan Pengumpulan Requirement untuk memahami struktur data dan isinya

termasuk mengidentifikasikan tipe dari pengguna, tahapan berikutnya melakukan

perancangan logis dari datawarehouse, selanjutnya dilakukan perancangan fisikal

dan parameter terkait, dan fase terakhir adalah kontruksi software. Keterkaitan

proses perancangan logical dan fisikal perlu didefinisikan per masing-masing role

dari designer khususnya berkaitan dengan rancangan dan administrasi dari

keseluruhan proses ETL. Pada perancangan logikan designer perlu

mengidentifikasi eksekusi plan dari setiap skenario, pendaftaran dari setiap job

ETL, skedul dari eksekusi, termasuk recovery plan atau pemrosesan ulang apabila

terdapat kegagalan eksekusi. Sedangkan dari sisi perancangan secara fisik perlu

pendefisian person in charge atau software yang bertanggung jawab melakukan

eksekusi workflow ETL serta pemeliharaan operasional.

Penelitian oleh (Vangipuram Radhakrishna, Vangipuram SravanKiran, K.

Ravikiran, 2012) mengenai otomasi proses ETL dengan teknologi scripting tanpa

ketergantungan dengan fitur dari ETL tools yang digunakan. Tekniknya dengan

mengumpulkan berbagai macam sumber data ke dalam target database terlebih

dahulu apa adanya dengan format data original serta kemungkinan struktur data

yang tidak terstruktur. Setelah data terkumpul di database tujuan, maka proses

selanjutnya adalah menggunakan scripting secara backend database untuk

menghandel spesifik proses ektrasi, transformasi dan load lengkap dengan

pendefinisian statistic dan error logging. Ketergantungan dengan ETL tools akan

membuat pemeliharaan secara manual akan setiap job yang menghandel proses

ETL satu persatu terhadap validitas sumber data dan proses transformasi ke

database tujuan.

Penelitian oleh (Angreine Kewo, 2013) pada 2013 International Conference of

Information and Communication Technology (ICoICT) bahwa Business

Intelligence (BI) dengan On line Analytical Processing (OLAP) memainkan peran

penting dalam dalam era kini. Tujuan dari penelitian ini adalah untuk merancang


33


dan membandingkan solusi OLAP yang berfokus pada industri bisnis makanan

yang diterapkan dalam studi kasus. Rancangan OLAP dilakukan dengan beberapa

langkah dimulai dari pengechekan relationship antar tabel dan melakukan data

cleansing untuk database tertentu, identifikasi kebutuhan informasi, melakukan

query terhadap kebutuhan informasi, melakukan perancangan dengan star skema,

melakukan proses ekstraksi, transformasi dan load, membuat design cube dan

melakukan presentasi di Microsoft Excel dengan menggunakan Pivot Tabel.

Perancangan OLAP dilakukan dengan menggunakan metode Kimball.

Penelitian oleh (Hasa & Hyland, 2010) mengenai Penggunaan OLAP dan data

multidimensional untuk pengambilan keputusan. Multidimensional database

sering digunakan dalam hubungannya dengan sebuah datawarehouse untuk

pendukung executive information system. Manager sering mengunakan informasi

dengan melakukan slice and dice, drilling down, rolling up dan melakukan

filtering atas data tertentu berdasarkan keinginan pengguna. Oleh karena itu

pendekatan dalam perancangan multidimensional dibedakan menjadi Relational

OLAP (ROLAP) dan Multidimensional OLAP (MOLAP). Pendekatan ROLAP

biasanya merupakan hasil dari bottom up approach yang fokusnya adalah sistem

yang sedang berjalan dan database yang dapat melakukan analisa terhadap

relational database secara on the fly, sedangkan MOLAP merupakan hasil dari top

down approach yang fokusnya adalah pada business planning. Keputusan

penggunaan ROLAP atau MOLAP adalah terkait dengan dilemma space dan

waktu. MOLAP akan melibatkan space yang lebih besar karena dengan

pembuatan physical cube, yang menyebabkan duplikasi namun mempunyai

kemampuan akses data yang lebih cepat. Sedangkan ROLAP menggunakan space

yang lebih sedikit namun terdapat kendala dari sisi kecepatan akses.

Penelitian oleh (Mary Breslin, 2004) pada business intelligence journal winter

mengenai perbandingan model antara Kimball dan Inmon, dimana pada

pendekatan Kimball merekomendasikan untuk membuat satu datamart per

masing-masing bisnis proses. Gabungan dari beberapa datamart di dalam

organisasi menggambarkan data warehouse, maka bus architecture memastikan

interoperability antara datamart yang ada. Kimball merekomendasikan bahwa


34


data model dimensional memegang peran dalam perancangan datamart, dimana

tabel fakta berisi data yang dapat diukur dan tabel dimensi merupakan hal yang

mengubah data. Pengguna dapat secara efektif merancang datamart dengan

kemudahan penggunaan dan renspon query yang lebih cepat dari hasil

perancangan datamart secara dimensional. Sedangkan pendekatan Inmon

mengarahkan penggunaan database tools dan methodology, seperti ERD, DIS dan

perancangannya banyak melibatkan IT daripada pengguna. Inmon metodologi

merupakan adaptasi dari pengembangan database secara tradisional dimana data

warehouse merupakan bagian yang lebih besar daripada pengembangan database,

atau lebih dikenal dengan Corporate Information Factory. Pendekatan Inmon

lebih cocok untuk pengembangan data warehouse secara enterprise yang bersifat

strategis untuk kepentingan perusahaan secara menyeluruh, bukan untuk

kepentingan departmen tertentu atau tujuan tertentu misalnya tujuan pelaporan.

Pada penelitian oleh (Sandip Singh, 2011) pada Journal of Global Research in

Computer Science, Volume 2, May 2011 mengenai perancangan data warehouse

dan metodenya menyimpulkan bahwa dari banyak arsitektur datamart yang

diteliti, Independent datamart merupakan solusi arsitektur yang dipilih apabila

sumber daya terbatas dan fokus kepada penggunaan informasi yang spesifik dan

ingin cepat tersaji dimana merupakan langkah awal dalam pengumpulan berbagai

informasi yang dibutuhkan oleh suatu department ke dalam suatu database,

namun terdapat kekurangan seperti kemungkinan akan redundant processing dan

redundant data. Sedangkan arsitektur menggunakan bus architecture dipilih

karena tingginya kebutuhan tukar menukar dan sharing data antara berbagai

departmen dengan implementasi yang cepat yang mana merupakan

penggabungan dari beberapa datamart yang ada menjadi datawarehouse.

Arsitektur terakhir adalah hub and spoke atau centralized architecture dipilih

apabila data warehouse merupakan bagian dari strategi enterprise dimana

dibutuhkan data yang paling granular antara berbagai sumber data yang dapat

digunakan secara independensi dengan satu sumber data yang sama.


35


2.7 Pedoman Akuntansi Perbankan Indonesia (PAPI)

2.7.1 Latar Belakang

Laporan keuangan bank bertujuan untuk menyediakan informasi yang

menyangkut posisi keuangan, kinerja serta perubahan posisi keuangan.Selain itu

laporan keuangan bank juga bertujuan untuk pengambilan keputusan. Suatu

laporan keuangan akan bermanfaat apabila informasi yang disajikan dalam

laporankeuangan tersebut dapat dipahami, relevan, andal dan dapat

diperbandingkan. Akan tetapi, perlu disadari pula bahwa laporan keuangan tidak

menyediakan semua informasi yang mungkin dibutuhkan oleh pihak-pihak yang

berkepentingan dengan bank, karena secara umum laporan keuangan hanya

menggambarkan pengaruh keuangan dari kejadian masa lalu, dan tidak

diwajibkan untuk menyediakan informasi non-keuangan. Walaupun demikian,

dalam beberapa hal bank perlu menyediakan informasi nonkeuangan yang

mempunyai pengaruh keuangan di masa depan.

2.7.2 Tujuan dan Ruang Lingkup

2.7.2.1 Tujuan

Tujuan dari penyusunan Pedoman Akuntansi Perbankan Indonesia (PAPI) antara

lain adalah:

a. Untuk membantu pengguna dalam menyusun laporan keuangan agar sesuai

dengan tujuannya, yaitu untuk:

1) Pengambilan keputusan investasi dan kredit

Laporan keuangan bertujuan untuk menyediakan informasi yang

bermanfaat bagi pihak-pihak yang berkepentingan dalam pengambilan

keputusan yang rasional. Oleh karena itu, informasinya harus dapat

dipahami oleh pelaku bisnis dan ekonomi serta pihak-pihak lain yang

berkepentingan antara lain meliputi: deposan, kreditur, pemegang saham,

otoritas pengawasan, Bank Indonesia, pemerintah, lembaga penjamin

simpanan, dan masyarakat.


36


2) Menilai prospek arus kas

Laporan keuangan bertujuan untuk memberikan informasi yang dapat

mendukung deposan, investor, kreditur dan pihak-pihak lain dalam

memperkirakan jumlah, saat, dan kepastian dalam penerimaan kas di masa

depan. Prospek penerimaan kas sangat tergantung pada kemampuan bank

untuk meng-hasilkan kas guna memenuhi kewajiban yang telah jatuh

tempo, kebutuhan operasional, reinvestasi dalam operasi, dan pembayaran

dividen. Persepsi dari pihak-pihak yang berkepentingan atas kemampuan

bank tersebut akan mempengaruhi harga pasar efek bank yang

bersangkutan. Persepsi mereka umumnya dipengaruhi oleh harapan atas

tingkat pengembalian dan risiko dari dana yang mereka tanamkan.

Deposan, investor, dan kreditur akan memaksimalkan pengembalian dana

yang telah mereka tanamkan dan akan melakukan penyesuaian terhadap

risiko yang mereka perkirakan akan terjadi pada bank yang bersangkutan.

3) Memberikan informasi atas sumber daya ekonomi

Pelaporan keuangan bertujuan memberikan informasi tentang sumber daya

ekonomi bank (economic resources), kewajiban bank untuk mengalihkan

sumber daya tersebut kepada entitas lain atau pemilik saham, serta

kemungkinan terjadinya transaksi dan peristiwa yang dapat mempengaruhi

perubahan sumber daya tersebut.

b. Menciptakan keseragaman dalam penerapan perlakuan akuntansi dan

penyajian laporan keuangan, sehingga meningkatkan daya banding diantara

laporan keuangan bank.

c. Menjadi acuan minimum yang harus dipenuhi oleh perbankan dalam

menyusun laporan keuangan. Namun keseragaman penyajian sebagaimana

diatur dalam PAPI tidak menghalangi masing-masing bank untuk memberikan

informasi yang relevan bagi pengguna laporan keuangan sesuai kondisi

masing-masing bank.

2.7.2.2 Ruang Lingkup

Pedoman Akuntansi Perbankan Indonesia (PAPI) berlaku untuk bank umum

konvensional. Dalam hal bank umum konvensional mempunyai unit usaha


37


syariah, maka unit usaha syariah tersebut menggunakan Pedoman Akuntansi

Perbankan Syariah Indonesia (PAPSI) kecuali untuk hal-hal yang tidak diatur

dalam Pedoman Akuntansi Perbankan Syariah Indonesia tersebut.

2.7.3 Perbedaan Perhitungan Pembentukan Penyisihan Aktiva Sebelum dan

Sesudah Menggunakan PSAK 50 dan 55

Sebelum PSAK 50 dan 55

Kolektibilitas yang ada di Bank sudah ditentukan oleh Bank Indonesia, dan

berdasarkan SK BI No. 31/148/KEP/DIR tanggal 12 november 1998,

pembentukan PPA minimal sebesar sebagai berikut:

a. Cadangan umum

kol. 1 → sebesar 1% x aktiva produktif lancar x risiko bank

b. Cadangan khusus

kol. 2→ sebesar 5% x aktiva produktif dalam perhatian khusus (DPK) x

risiko bank

kol. 3→ sebesar 15% x (aktiva produksi kurang lancar – nilai agunan) x

risiko bank

kol. 4→ sebesar 50% x (aktiva produktif diragukan – nilai agunan) x risiko

bank

kol. 5→ sebesar 100% x (aktiva produksi macet – nilai agunan) x risiko

bank

Agunan yang dapat dijadikan pengurang dalam pembentukan PPA terdiri dari:

Giro, deposito, tabungan dan setoran jaminan dalam mata uang rupiah dan

valuta asing yang diblokir disertai dengan surat kuasa pencairan.

Sertifikat Bank Indonesia dan surat utang pemerintah.

Surat berharga yang aktif diperdagangkan di pasar modal.

Tanah, gedung, rumah tinggal, pesawat udara, dan kapal laut dengan

ukuran diatas 20 kubik.


38


Setelah PSAK 50 dan 55

a. Apabila terdapat selisih dalam nilai tercatat kredit dan present value, maka

akan muncul akun cadangan kerugian penurunan nilai (CKPN)

b. Terdapat dua teknik evaluasi penurunan nilai yaitu secara individual dan

kolektif

c. Cadangan kerugian penurunan nilai kredit yang telah dibentuk bank dianggap

sebagai pembentukan penyisihan aktiva (PPA) yang telah dibentuk. Apabila

terdapat selisih kurang antara cadangan kerugian penurunan nilai yang telah

dibentuk dan PPA yang wajib dibentuk sesuai ketentuan Bank Indonesia,

maka selisih kurang tersebut harus diperhitungkan sebagai faktor

pengurangan modal inti dalam perhitungan Kewajiban Penyediaan Modal

Minimum (KPMM).

d. Pada semua kejadian yang termasuk dalam kategori bukti yang obyektif di

bawah ini maka nilai kreditnya harus diimpare (diturunkan).

2.7.4 Pengertian Penurunan Nilai

Penurunan nilai adalah suatu kondisi dimana terdapat bukti obyektif terjadinya

peristiwa yang merugikan sebagai akibat dari satu atau lebih peristiwa yang terjadi

setelah pengakuan awal kredit tersebut, dan peristiwa yang merugikan tersebut

berdampak pada estimasi arus kas masa datang atas aset keuangan atau kelompok

aset keuangan yang dapat diestimasi secara andal (PAPI, 2008). Cadangan

kerugian penurunan nilai kredit adalah penyisihan yang dibentuk apabila nilai

tercatat kredit setelah penurunan nilai kurang dari nilai tercatat awal (PAPI, 2008).

Penurunan nilai pada dasarnya disebabkan oleh dampak kombinasi dari beberapa

peristiwa. Kerugian yang diperkirakan timbul akibat peristiwa dimasa datang

tidak dapat diakui, terlepas hal tersebut sangat mungkin terjadi. Bukti obyektf

bahwa aset keuangan atau kelompok aset keuangan mengalami penurunan nilai

meliputi data yang dapat diobservasi yang menjadi perhatian dari pemegang aset

tersebut mengenai peristiwa-peristiwa yang merugikan berikut ini:

a) Kesulitan keuangan signifikan yang dialami penerbit atau pihak peminjam,


39


b) Pelanggaran kontrak, seperti terjadinya wanprestasi atau tunggakan

pembayaran pokok atau bunga,

c) Pihak pemberi pinjaman, dengan alasan ekonomi atau hukum sehubungan

dengan kesulitan keuangan yang dialami pihak peminjam, memberikan

keringanan (konsesi) pada pihak peminjam yang tidak mungkin diberikan jika

pihak peminjam tidak mengalami kesulitan tersebut,

d) Terdapat kemungkinan bahwa pihak peminjam akan dinyatakan pailit atau

melakukan reorganisasi keuangan lainnya,

e) Hilangnya pasar aktif dari aset keuangan akibat kesulitan keuangan, atau

f) Data yang dapat diobservasi mengindikasikan adanya penurunan yang dapat

diukur atas esti masi arus kas masa datang dari kelompok aset keuangan sejak

pengakuan awal aset dimaksud. Penurunan nilai mencakup seluruh kredit yang

tidak dievaluasi secara individual dan yang dievaluasi secara individual,

namun tidak terdapat bukti obyektif terjadinya penurunan nilai.

2.7.5 Kriteria Evaluasi Penurunan Nilai

Untuk dapat melalukan evaluasi, maka kita harus mengerti kriteria-kriteria yang

digunakan untuk mengevaluasi penurunan nilai. Kriteria evaluasi penurunan nilai

tersebut adalah sebagai berikut (PAPI, 2008:183):

A. Secara Individual

Bank wajib menentukan tingkat signifikansi kredit yang akan dievaluasi secara

individual yang disertai dengan dokumentasi yang memadai yang harus dikaji

ulang secara periodik;

Dalam hal tidak terdapat bukti obyektif penurunan nilai dari kredit yang

dievaluasi secara individual, maka kredit tersebut harus dimasukkan ke dalam

kategori kredit yang akan dievaluasi penurunan nilainya secara kolektif.

Dalam hal terdapat bukti obyektif penurunan nilai dari kredit yang dievaluasi

secara individual namun tidak terdapat kerugian penurunan nilai, maka kredit

tersebut tidak dimasukkan ke dalam kategori kredit yang akan dievaluasi

penurunan nilainya secara kolektif. Contoh: ketika debitur berada dalam kondisi


40


macet (tidak ada estimasi arus kas selain arus kas dari agunan), dimana nilai kini

arus kas agunan sama dengan atau lebih besar dari nilai tercatat kredit. Menurut

PAPI (2008:184) evaluasi secara individual didasarkan pada 2 konsep, yaitu:

1. Estimasi jumlah kerugian kredit didasarkan pada seluruh informasi yang

tersedia dan experienced credit judgement, serta memperhatikan berbagai

aspek seperti:

a) Kekuatan dan kemampuan debitur untuk membayar kembali kewajiban

(repayment capacity);

b) Jenis dan jumlah agunan;

c) Ketersediaan garansi; dan

d) Prospek usaha debitur di masa datang.

2. Estimasi jumlah yang dapat diperoleh kembali didasarkan pada identifikasi

arus kas masa datang dan estimasi nilai kini dari arus kas tersebut.

B. Secara kolektif

1. Evaluasi penurunan nilai secara kolektif mencakup seluruh kredit yang:

1. Tidak dievaluasi secara individual; dan

2. Dievaluasi secara individual, namun tidak terdapat bukti obyektif

terjadinya penurunan nilai.

2. Bank wajib mengelompokkan kredit yang akan dinilai secara kolektif

berdasarkan kesamaan karakteristik risiko kredit yang mengindikasikan

kemampuan debitur untuk membayar seluruh kewajiban yang jatuh tempo

sesuai persyaratan kontrak. Sebagai contoh, kredit dapat dikelompokkan

berdasarkan satu atau lebih karakteristik berikut ini:

a) Estimasi probabilitas terjadinya gagal bayar atau peringkat risiko

b) Kredit;

c) Tipe (contohnya, pinjaman kartu kredit);

d) Lokasi geografis;

e) Tipe jaminan;

f) Tipe pihak kedua (contoh, konsumen, bisnis, atau pemerintah);

g) Status tunggakan; dan

h) Jatuh tempo.


41


3. Pengelompokkan kredit berdasarkan kesamaan karakteristik tersebut harus

disertai dengan dokumentasi yang memadai yang dikaji ulang secara periodik.

Terhadap kredit yang dikelompokkan tersebut, bank harus melakukan evaluasi

apakah terdapat bukti obyektif terjadinya penurunan nilai. Hal-hal yang perlu

diperhatikan antara lain:

a) Terdapat data yang dapat diobservasi yang mengindikasikan terjadinya

penurunan dalam estimasi arus kas masa datang yang dapat diukur dari

kelompok kredit,

b) Penurunan yang dapat diukur tersebut telah terjadi sejak pengakuan awal

kredit, dan

c) Penurunan tersebut belum dapat diidentifikasi terkait dengan kredit

tertentu dalam kelompok kredit.

4. Evaluasi penurunan nilai secara kolektif merupakan langkah antara sampai

penurunan nilai kredit secara individual dapat diidentifikasi. Segera setelah

penurunan nilai suatu kredit secara individual dalam kelompok kredit tersebut

diidentifikasi, maka kredit tersebut harus dikeluarkan dari kelompok kredit

dan selanjutnya dinilai secara individual. Namun bank dapat

mempertimbangkan analisa biaya dan manfaat yang dituangkan dalam

kebijakan internal bank untuk menentukan apakah analisa individual perlu

dilakukan.

2.7.6 Penurunan Nilai dan Tidak Tertagihnya Aset Keuangan

Pada setiap tanggal neraca entitas mengevaluasi apakah terdapat bukti yang

objektif bahwa aset keuangan atau kelompok aset keuangan mengalami penurunan

nilai.

Aset keuangan atau kelompok aset keuangan diturunkan nilainya dan kerugian

penurunan nilai telah terjadi, jika dan hanya jika, terdapat bukti yang obyektif

mengenai penurunan nilai tersebut sebagai akibat dari satu atau lebih peristiwa

yang terjadi setelah pengakuan awal aset tersebut (peristiwa yang merugikan), dan

peristiwa yang merugikan tersebut berdampak pada estimasi arus kas masa depan

atau aset keuangan atau kelompok aset keuangan yang dapat diestimasi secara

andal.


42


Bukti obyektif bahwa aset keuangan atau kelompok aset keuangan mengalami

penurunan nilai meliputi data yang dapat diobservasi yang menjadi perhatian dari

pemegang aset tersebut mengenai peristiwa-peristiwa yang merugikan sebagai

berikut:

1. Kesulitan keuangan signifikan yang dialami penerbit atau pihak peminjam;

2. Pelanggaran kontrak, seperti terjadinya wanprestasi atau tunggakan

pembayaran pokok atau bunga;

3. Pihak pemberi pinjaman, dengan alasan ekonomi atau hukum sehubungan

dengan kesulitan keuangan yang dialami pihak peminjam, memberikan

keringanan (konsesi) pada pihak peminjam yang tidak mungkin diberikan jika

pihak peminjam tidak mengalami kesulitan tersebut;

4. Terdapat kemungkinan bahwa pihak peminjam akan dinyatakan pailit atau

melakukan reorganisasi keuangan lainnya;

5. Hilangnya pasar aktif dari aset keuangan akibat kesulitan keuangan;

6. Data yang dapat diobservasi mengindikasikan adanya penurunan yang dapat

diukur atas estimasi arus kas masa depan dari kelompok aset keuangan sejak

pengakuan awal aset yang dimaksud, meskipun penurunannya belum dapat

diidentifikasi terhadap aset keuangan secara individual dalam kelompok aset

tersebut, termasuk:

Memburuknya status pembayaran pihak peminjam dalam kelompok

tersebut (misalnya meningkatnya tunggakan pembayaran atau

meningkatnya jumlah pihak peminjam kartu kredit yang mencapai batas

kreditnya dan hanya mampu membayar cicilan bulanan minimal);

Kondisi ekonomi nasional atau lokal yang berkorelasi dengan wanprestasi

atas aset dalam kelompok tersebut (misalnya bertambahnya tingkat

pengangguran di area geografis pihak peminjam, turunnya harga properti

untuk kredit properti di wilayah yang relevan, turunnya harga minyak

untuk pinjaman yang diberikan kepada produsen minyak, atau

memburuknya kondisi industri yang mempengaruhi pihak peminjam

dalam setiap kelompok tersebut). .



BAB 3

METODOLOGI PENELITIAN

Pada bab ini akan menjelaskan langkah-langkah metodologi yang digunakan

dalam membahas permasalahan penelitian. Metodologi penelitian didasarkan dari

studi literatur penelitian sejenis mengenai perancangan datamart dan penelitian

mengenai requirement analysis dalam perancangan arsitektur dan proses ETL

untuk mendukung perancangan datamart yang baik. Maka dari itu metodologi

penelitian ini dirumuskan sesuai dengan gambar 3.1

Gambar 3.1 Metode Penelitian


44


3.1 Perumusan masalah

Dalam tahapan ini dilakukan penentuan pokok masalah dan tujuan dari penelitian,

berikut ruang lingkup penelitian. Diangkat dari regulasi Bank Indonesia melalui

Surat Edaran Bank Indonesia No. 11/4/DPNP mengenai Pelaksanaan Pedoman

Akuntansi Perbankan Indonesia (PAPI) dan No. 15/26/DPbs mengenai

pelaksanaan Pedoman Akuntansi Perbankan Syariah Indonesia (PAPSI), dimana

hal tersebut merupakan input dalam penelitian ini yaitu identifikasi kebutuhan

penerapan PSAK 50/55 dan observasi pada objek penelitian di Bank ‘X’

khususnya pada divisi keuangan, akuntansi dan manajemen risiko dalam rangka

penerapan regulasi Bank Indonesia yaitu penyisihan cadangan kerugian

penurunan nilai sesuai dengan PSAK 50/55.

Akan terdapat permasalahan baru untuk perbankan, apabila proses perhitungan

penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) ini dilakukan secara

manual, mengingat persyaratan yang diperlukan yaitu penggunaan data historis

pembiayaan selama 3 tahun terakhir, effort dalam pengumpulan data dari berbagai

source system pada objek penelitian, proses perhitungan berdasarkan berbagai

model statistika ditambah dengan penyesuaian dengan kebijakan yang ada di

masing-masing Bank. Kesemuanya itu tentunya terkait dengan lamanya waktu

yang diperlukan untuk menyediakan informasi final nilai perhitungan CKPN ini.

Termasuk concern lainnya adalah bahwa informasi ini dibutuhkan oleh

manajemen perusahaan untuk memutuskan langkah selanjutnya, bagaimana

dampak terhadap laporan rugi laba suatu bank atas hasil bentukan Cadangan

Kerugian Penurunan Nilai ini sesuai dengan PSAK 50/55. Dapat dirangkum

bahwa permasalahan bank tidak hanya fungsi untuk menghitung dan penyediaan

laporan tetapi juga terkait dengan analisa untuk menentukan keputusan

selanjutnya. Selanjutnya setelah didapatkan akar dari masalah dari penelitian yang

ada, maka dibentuk pertanyaan penelitian yang akan dijawab melalui penelitian

ini. Pertanyaan penelitiannya adalah Bagaimana rancangan dan implementasi

data mart dari Bank X yang sesuai dengan kebutuhan informasi regulator dalam

penyajian dan pengungkapan (PSAK 50) dan pengakuan dan pengukuran (PSAK


45


55) untuk ruang lingkup pelaporan dan monitoring penyisihan Cadangan

Kerugian Penurunan Nilai (CKPN) portfolio pembiayaan ?

3.2 Studi Literatur

Setelah dilakukan perumusan masalah, maka langkah berikutnya adalah

melakukan studi literatur untuk mempelajari landasan teori yang akan digunakan

dalam penelitian ini. Yang menjadi input pada tahapan studi literatur ini adalah

berupa pertanyaan penelitian, manajemen risiko kredit perbankan dan akuntansi,

jurnal-jurnal ilmiah, buku teks, dan tesis peneliti sebelumnya. Studi literatur

mencakup pemahaman teori-teori dasar seperti identifikasi dan analisa business

requirement berbasis proses ETL, perancangan arsitektur data warehouse,

perancangan data warehouse menurut Ralph R. Kimball, serta penelitian

sebelumnya, dimana hasil akhir dari studi literatur ini adalah theoretical

framework.

3.3 Pengumpulan Data

Proses pengumpulan data dilakukan pemahaman terhadap aturan dan petunjuk

dari regulator, dimana hal ini adalah mengacu kepada surat edaran Bank Indonesia

nomor 11/4/DPNP perihal pelaksanaan pedoman akuntansi perbankan Indonesia

dan nomor 15/26/DPbs perihal pelaksanaan Pedoman Akuntansi Perbankan

Syariah Indonesia.

Data juga dapat diambil melalui teknik observasi langsung ke Bank X untuk

memperoleh gambaran mengenai proses yang berjalan saat ini terkait dengan

proses pelaporan, proses penyimpanan data, dan pengolahan data yang digunakan

untuk menerapkan ketentuan dari Bank Indonesia dan Ikatan Akuntan Indonesia.

Observasi dilakukan dengan beberapa langkah antara lain dengan melakukan

pengamatan dan menganalisa kondisi objek penelitian, terutama pada

ketersediaan data dan alur informasi yang saat ini digunakan untuk mendukung

penerapan pelaporan sesuai dengan standard PSAK 50/55.

Metode pengumpulan data lainnya dilakukan dengan teknik wawancara dan

diskusi terutama terkait dengan kebutuhan bisnis yang disyaratkan menurut


46


standar PSAK 50/55. Wawancara dan diskusi dilakukan terhadap masing-masing

unit bisnis (divisi pembiayaan/kredit, divisi remedial, unit keuangan dan

akuntansi, unit teknologi informasi dan unit manajemen risiko) untuk memahami

proses yang ada saat ini baik dari sisi kebijakan dan operasional bisnis dan sumber

data yang digunakan.

Yang menjadi output pada tahapan ini berupa dokumentasi proses bisnis yang ada

sekarang, dan sumber data dari core banking system yang akan digunakan sebagai

input dalam rangka pembuatan data mart PSAK.

3.4 Analisis kebutuhan bisnis dan informasi

Pada tahap ini dilakukan analisa lebih dalam mengenai kebutuhan bisnis dan

informasi yang diharapkan oleh Divisi Keuangan, Akunting dan Manajemen

Risiko sebagai syarat kepatuhan (compliance) terhadap regulasi pelaporan

perbankan di Indonesia menurut standar akuntansi PSAK 50/55. Tahap

identifikasi dan analisis kebutuhan merupakan kelanjutan dari tahapan

pengumpulan data. Setelah data terkumpul baik dari sisi proses bisnis yang

berjalan sekarang dan sumber data yang akan digunakan pada objek penelitian di

Bank X, maka selanjutnya diperlukan analisa kebutuhan bisnis dan informasi yang

dibutuhkan dalam rangka penerapan pelaporan PSAK 50/55. Analisa ini

diperlukan agar dapat memberikan hasil yang sesuai dengan harapan yaitu dengan

menyajikan Gap Analysis business requirement PSAK 50/55 terhadap obyek

penelitian di Bank X berupa daftar laporan, daftar kebutuhan informasi, daftar

analisa dari setiap informasi, status ketersediaan sumber data, serta pemetaan

terhadap masing-masing sumber data termasuk didalamnya aturan transformasi

yang harus dipenuhi dalam penerapan datamart PSAK 50/55.

Gap Analisis didapatkan dengan membandingkan gap pemetaan proses bisnis dan

kebutuhan data pada keadaan sekarang dan ekspektasi yang dibutuhkan, sesuai

dengan kerangka dasar penyusunan pelaporan PSAK 50/55 sesuai dengan

standard Pedoman Akuntansi Perbankan Indonesia dan Pedoman Akuntansi

Perbankan Syariah Indonesia. Dalam hal ini fokus kepada analisis user

requirement khususnya untuk setiap proses bisnis akan tercermin pada proses


47


ETL yang menentukan sumber dan target dalam perancangan datamart PSAK

50/55.

3.5 Perancangan Arsitektur Datamart

Perancangan dan pemilihan arsitektur datamart PSAK 50/55 yang akan digunakan

dilakukan dengan membandingkan 2 model best practice arsitektur data

warehouse yaitu menurut Bill Inmon dengan model hub and spoke arsitektur dan

arsitektur data warehouse menurut Ralph Kimball yaitu dengan arsitektur

dimensional data model. Dasar pemilihan arsitektur tersebut didasarkan atas

beberapa kriteria yang harus diperhatikan sesuai dengan kebutuhan organisasi di

Bank X. Kriteria tersebut antara lain : Ketergantungan informasi antara

organisasi, perspektif approach, Data Orientation, Struktur Data, Persistency of

Data, Data Integration Requirements, Time to Delivery, Kemudahan Akses

Pengguna dan Profile Penggunanya, Time Frame, Nature of the organization’s

decision support requirements.

3.6 Perancangan dan Implementasi Datamart

Perancangan data warehouse pada penelitian ini dilakukan mengikuti 9 tahap

perancangan data warehouse menurut Kimball (Kimball & Ross, 2002), yaitu

mulai dari pemilihan proses, menentukan grain, identifikasi dan membuat

dimensi, pemetaaan sumber data ke tabel fakta, menentukan data pre-kalkulasi

dari tabel fakta, melengkapi tabel dimensi, memilih durasi dari basis data,

melacak dimensi yang berubah secara perlahan dan menentukan prioritas dan

mode dari query yaitu dengan mempresentasikan datamart ke dalam bentuk

laporan.

Selain dalam Dalam perancangan dan implementasi datamart ini, juga diperlukan

penentuan sumber data dan format atau tipe data, pembuatan ekstrak dari data

sumber dan proses data cleansing, bagaimana proses transformasi dilakukan,

kemudian pemuatan ke data mart dengan teknik dimensional data modeling. Oleh

karena itu yang menjadi output pada tahapan ini adalah data staging, proses ETL,

tabel fakta, tabel dimensi dan datamart.


48


3.7 Implementasi OLAP

Setelah rancangan datamart PSAK 50/55 terbentuk, maka tahapan berikutnya

adalah perancangan aplikasi pelaporan dan tools analisa yang akandigunakan oleh

divisi keuangan, akuntansi dan manajemen risiko. Melanjutkan dari perancangan

laporan ini kemudian akan dikembangkan untuk tools analisa dengan pengolahan

visualisasi Online Analytical Processing (OLAP). OLAP dapat mendayagunakan

konsep multidimensional dan memungkinkan para pemakai menganalisa data

sampai mendetail, tanpa mengetikkan satupun perintah query. Diharapkan dengan

adanya OLAP dapat dijadikan pertimbangan bagi eksekutif untuk membantu

dalam pengambilan keputusan. Yang menjadi output dalam tahapan ini adalah

visualisasi data melalui laporan PSAK 50/55 yang disyaratkan oleh regulator dan

OLAP untuk keperluan analisa masing-masing divisi terkait dengan alternatif

tools seperti Cognos Business Intelligence dan Microsoft SQL Server Analysis

Studio.

3.8 Kesimpulan dan Saran

Pada tahapan ini akan diperoleh jawaban dari pertanyaan penelitian yang telah

dilakukan. Kesimpulan berisi mengenai proses rancangan datamart dan penerapan

OLAP yang dapat membantu pengguna dan eksekutif dalam mempersiapkan data

hasil perhitungan CKPN menurut PSAK 50/55, persiapan laporan, monitoring dan

menganalisa mengenai besarnya penyisihan cadangan kerugian penurunan nilai

(CKPN) untuk portfolio pembiayaan di Bank ‘X’.



BAB 4

ANALISA, PERANCANGAN DAN IMPLEMENTASI DATAMART PSAK

50/55

Pada Bab membahas pokok permasalahan dari penelitian ini mengenai penerapan

perhitungan dan pelaporan penyisihan Cadangan Kerugian Penurunan Nilai

(CKPN) portfolio pembiayaan sesuai dengan PSAK 50/55 di Bank X.

Pemaparan diawali dari fase analisa kebutuhan bisnis berupa informasi dan data

dalam di Bank X, dengan dasar acuan berasal regulasi Bank Indonesia melalui

Surat Edaran Bank Indonesia No. 11/4/DPNP mengenai Pelaksanaan Pedoman

Akuntansi Perbankan Indonesia (PAPI) dan No. 15/26/DPbs mengenai

pelaksanaan Pedoman Akuntansi Perbankan Syariah Indonesia (PAPSI).

Selanjutnya pemaparan perancangan arsitektur datamart PSAK 50/55 sampai

dengan perancangan permodelan datamart PSAK 50/55

4.1 Identifikasi Kebutuhan Bisnis

Identifikasi kebutuhan bisnis dibagi menjadi beberapa fase proses, yaitu : fase

pengumpulan data, pemilihan proses bisnis, analisa kebutuhan informasi, analisa

kebutuhan pelaporan, analisa sumber data dan analisa transformasi business rule

melalui proses ETL.

4.1.1 Analisa Kebutuhan Informasi dan Proses Bisnis

Penurunan nilai (impairment) adalah suatu kondisi dimana terdapat bukti obyektif

terjadinya peristiwa yang merugikan sebagai akibat dari satu atau lebih peristiwa

yang terjadi setelah pengakuan awal kredit tersebut, dan peristiwa yang merugikan

tersebut berdampak pada estimasi arus kas masa datang atas aset keuangan atau

kelompok aset keuangan yang dapat diestimasi secara andal.

Terkait dengan penerapan PSAK 50 (Revisi 2006) dan PSAK 55 (Revisi 2006)

maka metode penyisihan kerugian (PPAP – Penyisihan Penghapusan Aktiva

Produktif, sesuai dengan Surat Keputusan Direksi Bank Indonesia


50


No.31/147/KEP/DIR tanggal 12 November 1998) tidak akan digunakan. Metode

penyisihan menggunakan metode incurred losses, yaitu menentukan CKPN

berdasarkan data historis kerugian kredit yang sudah terjadi Potential of default

yang dihitung dari pengalaman kerugian yang sudah terjadi berdasarkan data

historis setiap jenis kredit bank tersebut minimal selama 3 tahun terakhir

Seperti yang tertera pada PSAK 55, metode penyisihan yang digunakan dapat

dilakukan secara individual (specific assesment) atau kolektif (collective

assessment). Bank wajib mengelompokkan kredit yang akan dinilai secara

kolektif berdasarkan kesamaan karakteristik risiko kredit yang mengindikasikan

kemampuan debitur untuk membayar seluruh kewajiban yang jatuh tempo sesuai

persyaratan kontrak. Pada penelitian di Bank X dalam rangka perhitungan CKPN

kolektif, pengelompokkan collective group didasarkan kepada segmentasi dan

kualitas kolektibilitas. Berikut adalah beberapa istilah yang digunakan dalam

penghitungan penyisihan secara kolektif:

Exposure at Default (EXP), yaitu estimasi jumlah tingkat kemungkinan

terburuk atau tingkat maksimum dari kerugian yang akan dialami jika

suatu peristiwa atau transaksi mengalami wanprestasi pada periode

wanprestasi. Dalam hal ini, eksposur yang dimaksud adalah besarnya

jumlah kredit yang diberikan (outstanding). Outstanding adalah saldo

kredit yang telah digunakan debitur dan belum dilunasi oleh debitur.

Probability Default (PD), yaitu kemungkinan bahwa pihak peminjam dana

akan mengalami wanprestasi selama jangka waktu kewajiban yang ia

miliki atau dalam periode tertentu, misalnya satu tahun.

Loss Given Default (LGD), didefinisikan sebagai persentase kerugian yang

diperkirakan oleh pemberi kredit jika suatu debitur default. Dalam hal

wanprestasi, yaitu selisih antara bagian atas sejumlah nominal yang bisa

di-recover (misal: dari bankruptcy proceeding) dan aktual kerugian dengan

exposure at default.

Oleh karena itu perumusan perhitungan penyisihan cadangan kerugian penurunan

nilai (CKPN) kolektif adalah EXP x PD x LGD.


51


Sedangkan perumusan perhitungan penyisihan cadangan kerugian penurunan nilai

(CKPN) secara individual didasarkan pada estimasi arus kas dari masing-masing

akun, dimana arus kas merupakan estimasi jumlah yang dapat diperoleh kembali

berdasarkan identifikasi arus kas masa datang. Sehingga perhitungan CKPN

adalah nilai outstanding pada saat terjadi penurunan nilai secara individual

dikurangi dengan Estimasi Arus kas yang dapat di-recover.

Berdasarkan analisa kebutuhan informasi sesuai dengan persyaratan Bank

Indonesia melalui Surat Edaran Bank Indonesia nomor 11/4/DPNP perihal

pelaksanaan pedoman akuntansi perbankan Indonesia (PAPI) dan nomor

15/26/DPbs perihal pelaksanaan Pedoman Akuntansi Perbankan Syariah

Indonesia (PAPSI) dan Ikatan Akuntansi Indonesia (IAI) melalui PSAK 50 dan

PSAK 55, serta kebijakan manajemen internal bank X dalam proses bisnis

pemberian kredit, maka minimal laporan yang dibutuhkan untuk kepentingan

pelaporan ke regulasi dan analisa internal Bank X untuk tujuan pendukung

pengambilan keputusan sebagai berikut :

1. Laporan Total Pembiayaan berdasarkan Cabang.

2. Laporan Total Pembiayaan berdasarkan Produk dan Segment.

3. Laporan Total Pembiayaan berdasarkan Tanggal Jatuh Tempo. Pembiayaan

yang sudah jatuh tempo dan Pembiyaan yang belum jatuh tempo, untuk

pembiyaan yang belum jatuh tempo dikelompokkan berdasarkan periode

kelompok lamanya jatuh tempo).

4. Laporan distribusi pembiayaan yang mengalami perubahan kolektibilitas (ke

lebih baik atau lebih buruk atau pembiayaan tersebut telah jatuh tempo) dari

periode pelaporan bulan ini dan bulan sebelumnya per masing-masing produk,

segment, mata uang, cabang.

5. Laporan RatioNon Performing Loan per masing-masing cabang. Ratio Non

Perfoming Loan didapat dengan membagi total pembiayaan dalam mata uang

rupiah yang kolektibilitasnya pada kolektibilitas 3,4,5 dibagi dengan total

pembiayaan dalam mata uang rupiah secara keseluruhan per masing-masing

cabang.


dimana laporan ini berfungsi untuk menampilkan kecendrungan perubahan


52


nilai PD pada periode tertentu berdasarkan segementasi pengelompokkan

pembiayaan dan masing-masing kolektibilitas.

7. Laporan CKPN Kolektif / Collective Assesment Provision

Laporan yang berisi hasil dari perhitungan CKPN secara Kolektif berdasarkan

kelompokdari group of impairment.

8. Laporan Perbandingan antara CKPN Kolektif / Collective Assesment

Provision dengan PPAP (Penyisihan Penghapusan Aktiva Produktif)

berdasarkan segmentasi, cabang, produk, dan collective group impairment.

9. Laporan mengenai nilai variance antara CKPN actual dan CKPN forecast

untuk setiap cabang dan segmentasi pembiayaan.

10. Laporan Impairment Loan Ratio per masing-masing cabang. Impairment Ratio

ini didapat dengan membagi total CKPN dalam mata uang Rupiah dibagi

dengan total pembiayaan dalam mata uang Rupiah per masing-masing cabang.

11. Laporan Movement CKPN (Charged atau Released) untuk setiap cabang

dalam mata uang rupiah. Charged berarti diperlukan tambahan sejumlah biaya

tertentu sebagai tambahan biaya pembentukan CKPN. Sedangkan released

berarti terdapat pengurangan biaya CKPN dibandingkan dengan bulan

sebelumnya.

12. Laporan Klasifikasi Loan Impairment dan Pembiayaan berdasarkan

Segmentasi

13. Laporan Individual Impairment. Laporan Individual Impairment berisi

informasi daftar customer number yang sudah di daftarkan dengan flag

individual impairment.

Melihat kebutuhan informasi berupa laporan yang dipaparkan diatas, maka

diperlukan data di level detail terkait dengan masing-masing laporan tersebut.

Data-data yang dibutuhkan pada sumber data yang terdapat pada Bank X dapat

dirangkum menjadi 3 kelompok laporan;

1. Laporan Total Pembiayaan berdasarkan Cabang, Laporan Total Pembiayaan

berdasarkan Produk dan Segment, Laporan Ratio Non Performing Loan per

masing-masing cabang, Laporan Total Pembiayaan berdasarkan Tanggal Jatuh

Tempo dan Laporan distribusi pembiayaan yang mengalami perubahan

kolektibilitas.


53


Dari kelima laporan ini diperlukan informasi mengenai tanggal pelaporan,

kode cabang, nama cabang, nomor account pembiayaan, nomor fasilitas,

nomor nasabah, nama nasabah, jumlah fasilitas kredit (plafond), nilai

pembiayaan yang diberikan (outstanding), tanggal pembukaan rekening

pembiayaan (loan start date), tamggal jatuh tempo pembiayaan (loan due

date), tingkat suku bunga pembiayaan, mata uang yang digunakan,

segmentasi, kode produk dan kolektibilitas.


Laporan CKPN Kolektif, Laporan Perbandingan antara CKPN Kolektif /

Collective Assesment Provision dengan PPAP berdasarkan segmentasi,

Laporan mengenai nilai variance antara CKPN actual dan CKPN forecast

untuk setiap cabang dan segmentasi pembiayaan, Laporan Impairment Loan

Ratio per masing-masing cabang, Laporan Movement CKPN (Charged atau

Released) untuk setiap cabang dalam mata uang rupiah.

Dari keenam laporan diatas, informasi yang diperlukan adalah tanggal

pelaporan, segmentasi group ofimpairment, kolektibilitas per nomor nasabah,

nomor nasabah, nilai persentase PD per segementasi dan per kolektibilitas,

nilai persentase LGD per segementasi dan per kolektibilitas, metode

perhitungan PD, metode perhitungan LGD, nilai pembiyaan yang diberikan

per masing-masing kolektibilitas, nilai agunan yang diperhitungkan, nilai

recovery, nilai writeoff, nilai PPAP, nilai CKPN forecast, Nilai Impairment

Loan Ratio, dan status dari pembiayaan.

3. Laporan Klasifikasi Loan Impairment dan jumlah pembiayaannya berdasarkan

cabang, segmentasi dan Laporan Individual Impairment. Dari kedua laporan

ini, informasi yang diperlukan adalah tanggal pelaporan, segmentasi

impairment, klasifikasi flag impairment, nilai outstanding, nilai CKPN

Kolektif, Nilai CKPN Individual, informasi rincian debitur termasuk rincian

akad pembiayaannya (nomor debitur, nama debitur, mata uang, tanggal akad

pembiayaan, kolektibilitas, nama cabang, kode cabang, dan segmentasi).

Melalui tabel 4.1 dipaparkan secara lebih mendetail masing-masing mengenai

daftar kebutuhan informasi, kebutuhan analisa dan pelaporan, serta

statusketersediaan data (sumber sistem dan durasi data) sebagai bagian dari proses


54


identifikasi kebutuhan bisnis. Struktur tabel akan dibedakan menjadi 3 kolom

sebagai berikut:

1. Kebutuhan informasi : menjelaskan informasi apa saja yang dibutuhkan

untuk pembentukan laporan-laporan diatas sesuai dengan penerapan

perhitungan penyisihan kredit sesuai dengan PSAK 50/55

2. Kebutuhan analisa dan pelaporan : menjelaskan detail/deskripsi informasi

pada kolom kebutuhan informasi dalam proses pembuatan laporan dan

kapabilitas analisa yang akan digunakan oleh pengguna terkait dengan

masing-masing informasi tersebut.

3. Ketersediaan Data: Menjelaskan apakah informasi yang disyaratkan

tersedia pada core banking dan sistem yang ada di Bank X (availability),

bagaimana durasi data yang akan digunakan (bulanan pada setiap akhir

bulan, data histori 3 tahun, atau harian), dan nama sumber sistem dimana

data tersebut berasal.


55


Tabel 4.1 Tabel DaftarKebutuhan Informasi dan Kebutuhan Analisa

No. Kebutuhan Informasi Kebutuhan Analisa dan Pelaporan Satus Ketersediaan Data,

Sumber Sistem, Durasi Data

1 Nomor Pembiayaan/Nomor Akad

setiap adanya pencairan kredit dari

Bank sesuai dengan Fasilitas/Plafond

Kredit dari masing-masing debitur

Merupakan identifier data pembiayaan / kredit yang paling detail (data rincian)

granular. Pengguna dapat melakukan break down pelaporan laporan dari level

summary sampai ke level nomor pembiayaan pada masing-masing laporan yang

terkait dengan informasi ini. Misalnya : Pengguna akan melihat rincian per nomor akad

pembiayaan yang memiliki kontribusi top 10 terbesar di suatu cabang.

CARD = Y

iLoan = Y

JF = Y

Data selama 3 tahun terakhir

(2011, 2012, 2013)

2 Nomor Nasabah / Customer Number

/ CIF dari setiap pembiayaan

Mengacu kepada konsep One Obligor untuk penetapan kualitas aktiva produktif (PBI

No. 7/2/PBI/2005 dan PBI No. 8/2/PBI/2006). Setiap Nasabah dapat mempunyai

banyak fasilitas pembiayaan dan setiap fasilitas pembiayaan dapat dicairkan berkali-

kali menjadi nomor akad/pembiayaan. Customer Number ini akan digunakan sebagai

identifier dalam pengelompokkan data pembiayaan untuk menentukan pergerakan

kolektibilitas. Hal ini terkait dengan formulasi perhitungan Probability Default dengan

metode Migration Analysis.

CARD = Y

iLoan = Y

JF = Y


(2011, 2012, 2013)

3 Jumlah Nilai Fasilitas Kredit

(Plafond) dan Nilai Kredit yang

diberikan (Outstanding) per masing-

masing nomor rekening pembiayaan

/ nomor akad pembiayaan/kredit.

Plafond yaitu Jumlah maksimum kredit yang diterima oleh debitur sebagaimana

tercantum dalam surat perjanjian/kredit. Informasi mengenai plafond dan outstanding

digunakan sebagai pengukuran kinerja di suatu cabang di Bank X.

CARD = Y, iLoan = Y, JF = Y


untuk posisi akhir bulan

pelaporan (2011, 2012, 2013)

4 Tanggal pembukaan rekening

pembiayaan (Loan Start Date)dan

Tanggal Jatuh Tempo Pembiayaan

(Maturity Date)

Informasi mengenai Loan Start Date akan digunakan dalam penyusunan laporan

pembiayaan setiap bulannya. Informasi ini akan digunakan dalam laporan maturity

profile yaitu kredit yang sudah jatuh tempo dan yang belum jatuh tempo. Tujuan

analisa untuk mengevaluasi periode evaluasi kredit (loan review)

CARD = Y, iLoan = Y,JF = Y


untuk posisi bulan pelaporan

(2011, 2012, 2013)


56




5. Kolektibilitas/Kualitas Kredit dan

Tanggal perubahan kualitas kredit

berdasarkan Kolektibilitas BI (Bank

Indonesia) per masing-masing nomor

pembiayaan

Penggolongan kredit menurut kualitas, terdiri dari kredit dengan kualitas lancar (L) –

Kolektibilitas 1, dalam perhatian khusus (DPK) – Kolektibilitas 2, kurang lancar (KL)

– Kolektibilitas 3, diragukan (D) – Kolektiblitias 4, dan macet (M) – Kolektibilitas 5.

Penggolongan ini dilakukan untuk kepentingan penerapan prinsip kehati-hatian bank

(prudential regulation) dan digunakan untuk proses perhitungan Probability Default

dengan menggunakan metode statistik Net Flow Rate ataupun Migration Analysis.

Analisa lain yang dapat diperoleh untuk mengelompokkan sebaran data-data

pembiayaan berdasarkan kualitas kredit yang ada di setiap cabang.

CARD = Y,iLoan = Y,JF = Y



(2011, 2012, 2013)

6 Lamanya Tunggakan (Day Past Due

–DPD) per masing-masing nomor

pembiayaan

Data ini akan digunakan dalam membuat pengkategorian group collective impairment

berdasarkan range/sebaran lamanya hari menunggak tertentu, misalnya : 0 hari, 1-30

hari, 31-60 hari, 61-90 hari, dsb.

CARD = Y

iLoan = Y

JF = Y



(2011, 2012, 2013)

7 Status dari Pembiayaan per nomor

rekening (Status Active,

Restrukturisasi, Lunas sesuai dengan

tanggal jatuh tempo, Pelunasan

dipercepat, dan Write Off /Hapus

Buku)

Data Status pembiayaan ini akan digunakan dalam perhitungan Probability Default

menggunakan net flow rate dan migration analysis. Untuk status active dalam

migration analysis, apabila status berubah menjadi tidak aktif (account hilang) maka

dianggap turun bucket di group bucket.

CARD = Y, iLoan = Y, JF = Y



(2011, 2012, 2013)


57




8 Tingkat Suku Bunga yang diberikan

per nomor rekening pembiayaan

beserta tenor / jangka waktu

pembiayaan

Bunga kredit adalah imbalan yang dibayarkan oleh debitur atas kredit yang

diterimanya dan biasanya dinyatakan dalam persentase. Suku bunga efektif yang

dihitung berdasarkan arus kas kontraktual pada dasarnya tidak dapat diubah sampai

dengan seluruh kewajiban debitur dibayar lunas, termasuk ketika bank memberikan

keringanan suku bunga melalui restrukturisasi kredit atau melakukan revisi estimasi

pembayaran atau penerimaan bunga dan pokok. Tingkat suku bunga ini digunakan

dalam membuat estimasi arus kas, sebagai syarat dalam proses perhitungan CKPN

secara individual

CARD = Y

iLoan = Y

CB = Y

JF = Y

Data posisi pada periode bulan

pelaporan

9 Ratio Non Performing Loan dan

Ratio Impairment Loan

Merupakan informasi turunan dari informasi mengenai outstanding, total CKPN

dikelompokkan per masing-masing cabang. Informasi ini digunakan untuk melakukan

analisa kinerja dari setiap cabang.

Data ini akan ditransform

menggunakan proses batch ETL

berdasarkan Formula business

rule yang disepakati.

10 Jenis Mata Uang (Currency) per

masing-masing nomor pembiayaan

dan Nilai Tukarnya (Exchange Rate)

secara harian

Akan digunakan untuk klasifikasi pembiayaan berdasarkan valuta asing dan risiko nilai

tukar pada saat akad dan pada saat pelaporan, karena laporan regulasi Bank Indonesia

adalah dalam bentuk mata uang Rupiah.

MIS Database Daily

Data informasi nilai tukar untuk

masing-masing mata uang

setiap harinya.

11 Nilai Agunan yang diperhitungkan Nilai Agunan merupakan syarat dalam menghitung Loss Given Default (LGD)

menggunakan metode Collateral Shortfall untuk masing-masing pembiayaan dan

group segmentasi kredit.

Sumber data berasal dari

inputan user secara manual

melalui flat file Microsoft

Excel. Data ini diupdate secara

bulanan..


58




12 Nilai Hapus Buku / Write Off Data yang dibutuhkan untuk perhitungan Loss Given Default (LGD) menggunakan

metode expected recovery





bulanan.

13 Nilai Recovery Nilai pengembalian dari hasil pembayaran oleh nasabah, dimana informasi nilai

recovery ini diperlukan dalam komponen perhitungan LGD dengan menggunakan

metode expected recovery





bulanan.

14 Penentuan segmentasi pada

pembiayaan

Klasifikasi segmentasi pembiayaan pada bank yang dapat dibedakan menjadi:

Consumer Mortgage, Consumer Auto Loan, Consumer Kopkar, Consumer Pension,

Consumer Multipurpose, Corporate, SME, Micro, Corporate Syndication Loan.

MIS Database dengan posisi

akhir bulan pelaporan

15 Kriteria Parameter CollectiveGroup

untuk bucket perhitungan Probability

Default (PD) dan Loss Given Default

(LGD)

Berdasarkan data historis dan segmentasi dari Bank dari masing-masing pembiayaan,

maka informasi parameter collective group diperlukan sebagai komponen input untuk

perhitungan PD dan LGD. Data ini akan digunakan dalam proses transformasi data

staging untuk menghasilkan nilai CKPN





bulanan.

16 Klasifikasi Impairment Assesment,

apakah nomor rekening tersebut

terklasifikasi secara individual atau

terklasifikasi secara kolektif

Untuk mengetahui porsi dari klasifikasi impairment / penurunan nilai secara kolektif

dan individual per masing-masing segmentasi, masing-masing debitur dan masing-

masing account number. Data ini akan digunakan dalam proses transformasi data

staging untuk menghasilkan flag impairment.

Di-input oleh user secara

manual melalui flat file

Microsoft Excel. Data ini di-

update secara bulanan.


59




17 Proses dengan Metode Statistik

untuk perhitungan PD per masing-

masing segmentasi, apakah

menggunakan metode net flow rate

atau menggunakan metode migration

analysis dan masing-masing

kriterianya

Hasil dari Probability of Default (berupa persentase) per masing-masing collective

group yang sudah ditentukan dengan mengikuti kebijakan dan regulasi untuk

pemilihan metode yang digunakan. Proses Perhitungan PD dengan masing-masing

metode dilakukan pada saat proses transformasi data staging

Data ini akan di-transform




18 Proses Perhitungan LGD (Loss

Given Default) per masing-masing

segmentasi. Pilihan metode

perhitungan LGD adalah Collateral

Shortfall dan Expected Recoveries

Hasil dari Loss Given Default (persentase) per masing-masing collective group yang

sudah ditentukan dengan mengikuti kebijakan dan regulasi untuk pemilihan metode

yang digunakan. Proses Perhitungan LGD dengan dilakukan pada saat proses

transformasi data staging.





19 Nilai Penyisihan Piutang Aktivta

Produktif / PPAP menggunakan

metode expected loss

Merupakan nilai pembentukan provisi berdasarkan aturan PPAP berdasarkan

kolektibilitas. Formulasinya adalah jika kolektibilitas 1, maka nilai outstanding

dikalikan dengan 1%, jika kolektibilitas 2, maka nilai outstanding dikalikan dengan

5%, jika kolektibilitas 3 maka nilai outstanding dikalikan dengan 15%, jika

kolektibilitas 4 maka nilai outstanding dikalikan dengan 50% dan jika kolektibilitas 5

maka nilai outstanding dikalikan dengan 100%






60




20 Nilai Cadangan Kerugian Penurunan

Nilai (CKPN)

Merupakan Output akhir yang diharapkan dari penerapan PSAK 50/55. Berupa Nilai

Final dari proses perhitungan CKPN dari setiap pembiayaan per level account. Apabila

Klasifikasi Impairment Kolektif maka nilai dari CKPN adalah PD x LGD x

Outstanding. Apabila diklasifikasi secara individual maka diperoleh dengan hasil

formulasi Net Present Value dari estimasi arus kas yang ada.

Diperoleh melalui proses

transformasi dari batch ETL

setiap bulan pelaporan.

21 Nilai Charged atau Nilai Released

CKPN

Merupakan turunan informasi dari CKPN dengan membandingkan nilai CKPN bulan

ini dengan nilai CKPN bulan sebelumnya dalam mata uang IDR. Disebut Charged

apabila Nilai CKPN pada bulan ini lebih besar daripada bulan sebelumnya dan disebut

released apabila Nilai CKPN bulan ini lebih kecil dari bulan sebelumnya

Diperoleh melalui proses

transformasi dari batch ETL

setiap bulan pelaporan

22 Nilai CKPN Target / Forecast Merupakan informasi mengenai target pembentukan CKPN dalam mata uang Rupiah

per masing-masing cabang. Target CKPN ini diinput secara manual oleh User melalui

flat file per masing-masing cabang, kemudian melalui proses transformasi akan

dilakukan transformasi menjadi per level debitur. Informasi ini digunakan sebagai

proses analisa varianceantara Target dan Aktual CKPN





bulanan.


61


Pada gambar 4.1 akan dijelaskan alur proses bisnis dalam rangka perhitungan

penyisihan CKPN di Bank X berdasarkan kebutuhan pelaporan, analisa kebutuhan

fungsional, dan ketersediaan sumber data di Bank X. Alur bisnis ini merupakan

bagian dalam proses data preparation dan transformasi dari sumber data ke tabel

tujuan sesuai dengan analisa kebutuhan informasi yang diperlukan dalam rangka

mengakomodir penerapan perhitungan CKPN sesuai PSAK 50/55

Gambar 4.1 Alur Proses Perhitungan CKPN

Keterangan alur proses transformasi perhitungan CKPN

1. Tahap ke-1 yaitu data yang berasal dari multiple source system pembiayaan

(CRD, ILN, JF) dari masing-masing tabel akan dibuat stagingnya dan di

mapping untuk dikumpulkan ke suatu tabel PSAK_MASTER_ACCOUNT

2. Tahap ke-2 yaitu proses impairment dilakukan secara bulanan, menggunakan

data posisi/snapshot pembiayaan di akhir bulan, sesuai dengan parameter

tanggal proses impairment.

3. Setelah semua data pembiayaan terkumpul ke dalam suatu tabel, maka proses

selanjutnya adalah melakukan proses segmentasi ke collective impairment

group. Proses segmentasi collective impairment group merupakan proses awal

untuk mengumpulkan jenis-jenis pembiayaan berdasarkan karakteristiknya

Informasi Collective Impairment Group ini merupakan parameter yang

dimaintain oleh pengguna secara manual untuk masing-masing segmentasi

pembiayaan dimapping collective impairment groupnya. Misalnya:

Segmentasi 42_CONSUMER_AUTO LOAN merupakan group pembiayaan

kendaraan bermotor, ditransfromasi menjadi segment AUTO,

11_CORPORATE_COMMERCIAL, 12_CORPORATE_UPPER SME,

13_CORPORATE_SYNDICATION, 14_CORPORATE_FI_EXECUTING,


62


15_CORPORATE_BANK ditranformasi menjadi segment CORPORATE.

Proses transformasi Segmentasi ini diambil dari data rincian pembiayaan pada

tabel PSAK_MASTER_ACCOUNT field C09_SEGMENTASI_ACCOUNT

di-mappingkan dengan tabel parameter PSAK_SEGMENT field

Collective_Group_1 untuk rule klasifikasi gruping segment ini. Grup

Segmentation (Collective Group) akan digunakan dalam perhitungan

Impairment secara kolektif yang nantinya akan digunakan dalam perhitungan

PD (Probability of Default) dan LGD (Loss Given Default)

4. Setelah dilakukan proses segmentasi berdasarkan collective impairment grup

yang telah di sepakati sesuai dengan kebijakan bank untuk segmentasi

pembiayaan. Maka selanjutnya transformasi kepada proses Impairment

Classification. Per masing-masing pembiayaan akan dilakukan proses

flagging. Flagging ‘C’ merupakan flag yang menunjukkan kalkulasi dihitung

dengan pendekatan Collective Assesment dan Flagging ‘I’, merupakan flaging

dengan pendekatan Individual Assesment. Flaging ini merupakan identifier

dari Impairment Type, proses transformasi berikutnya yaitu menentukan cara

perhitungan CKPN, apakah akan dihitung menggunakan Collective Assesment

atau Individual Assesment dengan masing-masing business rule yang sesuai

dengan aturan Surat Edaran BI dan PSAK 50/55 serta Kebijakan Internal

Bank. Untuk flagging secara individual dilakukan oleh user secara manual

memberikan upload data per level account untuk daftar pembiayaan mana saja

yang akan di flag secara individual. Sedangkan akun pembiayaan yang tidak

di flag secara individual akan dikategorisasikan secara otomatis menjadi flag

collective.

5. Apabila flagging adalah C (collective assessment) maka proses selanjutnya

adalah Transformasi data dalam melakukan kalkulasi Loss Given Default

(LGD)sesuai dengan metodologi yang digunakan (Collateral Shortfal dan

Expected Recoveries) dengan melakukan lookup ke tabel parameter LGD.

6. Setelah proses transformasi LGD kemudian akan dilakukan kalkulasi

perhitungan Probability Default (PD) dengan menggunakan metode net flow

rateatau migration analysis sesuai dengan segmentasi yang telah ditentukan.


63


7. Setelah LGD dan PD terbentuk maka transformasi terhadap nilai CKPN

Kolektif yaitu dengan mengalikan komponen Outstanding x Probability

Default(PD) dan Loss Given Default (LGD) di level akun pembiayaan.

8. Apabila Flagging adalah I (Individual Assesment) maka diperlukan input

manual arus kas per masing-masing debitur termasuk perhitungan nilai CKPN

Individual. Kriteria account-account pembiyaan dengan assesment secara

Individual adalah account-account pembiayaan yang kolektibilitasnya diatas 3

dan nilai pembiayaannya lebih dari Rp. 10 milyar.

9. Mengumpulkan semua nilai CKPN baik individual dan kolektif dari hasil step

transformasi diatas ke dalam suatu tabel PSAK_MASTER_ACCOUNT

4.1.2 Analisa Sumber Data

Setelah dilakukan analisa terhadap kebutuhan informasi dan kebutuhan pelaporan,

maka langkah berikutnya adalah menginventarisasi kebutuhan data yang

digunakan sebagai jawaban atas kebutuhan informasi dan kebutuhan analisa yang

tertera pada Tabel 4.1 diatas.

Berikut ini Tabel 4.2 mengenai daftar sumber data yang diperlukan dalam

penerapan perhitungan Cadangan Kerugian Penurunan Nilai (CKPN) produk

Pembiayaan. Sumber data dapat berasal dari Core Banking System, MIS Database,

Manual Input, dan dari hasil transformasi data staging pada database PSAK.


64


Tabel 4.2 Tabel Sumber Data Yang Akan Digunakan

Nama Tabel Deskripsi Sumber Data Jumlah

Data

Durasi

LOAN_DAILY Tabel yang berisi master pembiayaan beserta atribut yang terkait

dengan pembiayan (misalnya : account number, kolektibilitas, day

past due, loan due date) yang berasal dari source systemcore

banking Bank X. Tabel ini unique menyimpan per level account

number.

Core Banking

Systems

157.659 Posisi Akhir Bulanan

CUSTOMER Tabel yang berisi informasi data master customer seluruh

pembiayaan

MIS Database 43.345 Posisi Akhir Bulanan

MASTER_KURS_DAILY Tabel yang berisi informasi data kurs harian MIS Database 84 Harian (Day – 1)

MASTER_ BRANCH Tabel yang berisi master nama cabang Core Banking

Systems

465 Posisi Akhir Bulanan

FACILITY_DAILY Tabel yang berisi fasilitas dari masing-masing customer Core Banking

Systems 88.7012

Posisi Akhir Bulanan

LOAN_CARD_DAILY Tabel yang menampung master pembiayaan kartu kredit Core Banking

Systems

124,234 Posisi Akhir Bulanan

FACILITY_CARD_DAILY Tabel yang menampung fasilitas khusus pembiayaan kartu kredit

dari setiap nasabah.

Core Banking

Systems

343,894 Posisi Akhir Bulanan

TRANSACTION_DAILY Tabel yang berisi transaksi dari setiap akun pembiayaan (mis :

transaksi charging biaya administratif, biaya provisi, pembayaran,

dan sebagainya)

Core Banking

Systems

1.242.776 Harian (Accumulated dari

hari ke-1 s/d hari ke-End

of month bulan laporan)


65



Data

Durasi

COLLATERAL_DAILY Tabel yang menampung nilai dari agunan / collateral per masing-

masing fasilitas.

Core Banking

Systems

167.552 Tanggal Posisi Akhir

Bulanan

MASTER_ACCOUNT_WO Tabel yang berisi data master account dan attribute lainya yang

mengalami status Write Off

Core Banking

Systems


Bulanan

WO_RECOVERY_SUMMAR

Y

Summary dari nilai dariWO dan Recovery per segment Core Banking

Systems

Tanggal Posisi Akhir

Bulanan

PSAK_MASTER_ACCOUNT Semua informasi berikut attribute terkait untuk posisi account

number detail pembiayaan selama periode bulan pelaporan (end of

month) dengan status active.

Hasil Proses

Transformasi


Bulanan

PSAK_BMI_SEGMENT Parameter Collective Group yang terdiri dari mapping nama

segment yang digunakan untuk penentuan perhitungan Probability

Default dan Loss Given Default

Manual Input SCD

Tanggal Posisi Akhir

Bulanan

PSAK_DPD_MASTER_HEAD

ER

Tabel psak collective impairment parameter header Manual Input SCD Harian

PSAK_DPD_MASTER Parameter dari range atau sebaran lamanya hari menunggak (Day

past due) detail

Manual Input SCD Harian

PSAK_MASTER_PRODUCT_

PARAMETER

Daftar dari Product Code yang ada seluruh pembiayaan Core Banking

Systems dan

Manual Input

SCD Harian

PSAK_ENR Tabel yang berisi snapshot outstanding per periode berdasarkan

penentuan bucket collective groupsecara metode net flow rate

Hasil Proses

Transformasi

Snapshot Bulanan


66



Data

Durasi

PSAK_ENR_MIGRATION Tabel yang berisi snapshot outstanding per periode berdasarkan

penentuan bucket collective group secara metode migration

analysis

Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_FLOW_RATES Tabel berisi histori flow rate pergerakan antar bucket / group setiap

periode pelaporan, digrouping berdasakan collective group dan

bucket id untuk metode net flow rate

Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_FLOWRATE_MIGRAT

ION

Tabel berisi histori flow rate pergerakan antar bucket / group setiap

periode pelaporan, digrouping berdasakarn collective group dan

bucket id untuk metode migration analysis

Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_COMPOUND_FLOW_

TO_LOSS

Tabel psak compound flow to loss yang berisi perhitungan

pengalian nilai PD untuk series periode terakhir. Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_RECOVERY_MATRIX Tabel psak LGD yang berisi summary dari PD dan LGD yang

sudah dihitung per masing-masing collective group of impairment. Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_PD Tabel yang menyimpan nilai PD dan LGD untuk semua

perhitungan baik menggunakan metode Net flow rate atau

Migration Analysis. Jumlah records tergantung dari parameter

bucket collective group setting perhitungan PD. Misalnya

Collective group sebanyak 5 Group, dengan masing-masing grup

terdapat 5 ucket, maka untuk data selama periode setahun, maka

jumlah records adalah 12 x 5 x 5 = 300

Hasil Proses

Transformasi

Snapshot Bulanan

PSAK_LGD_SETTING Tabel psak lgd setting parameter. Collateral Shortfall atau

Expected Recoveries untuk masing-masing impairment group

Manual Input SCD Bulanan


67



Data

Durasi

PSAK_EXPECTED_RECOVE

RY

Tabel psak lgd expected recovery yang berisi summary dari setiap

recovery per masing-masing group of impairment

Manual Input Snapshot Bulanan

PSAK_LGD_COLLATERAL_

SHORTFALL

Tabel psak lgd collateral shortfall yang berisi summary dari setiap

collateral/jaminan per masing-masing group of impairment


PSAK_IMPR_OVERRIDES Tabel yang berisi nilai overrides individual or collective. Manual Input Snapshot Bulanan

PSAK_INDIVIDUAL_IMPAIR

MENT

Tabel yang berisi sebagai tempat penampung data per level akun

pembiayaan untuk setiap customer untuk setiap periode pelaporan.

Satu customer memungkinkan memiliki banyak akun pembiayaan.

Format file dalam bentuk Microsoft Excel


TBLT_PAYMENTEXPECTED Tabel yang berisi data arus kas yang di-upload oleh pengguna dan

langsung diproses insert ke tabel ini. File Format dalam bentuk

Microsoft Excel.


PSAK_EXPECTED_RECOV_UPL

OAD Berisi data write off dan recovery berdasarkan masing-masing

segmentasi yang di-upload langsung oleh pengguna. File Format

dalam bentuk Microsoft Excel.


PSAK_COLL_SHORTFALL_UPL

OAD berisi data collateral berdasarakan masing-masing segmentasi yang

di-upload langsung ke suatu folder. File Format dalam bentuk

Microsoft Excel.


PSAK_CKPN_TARGET berisi data target pembentukan cadangan kerugian penurunan nilai

setiap bulannya dan di-upload langsung ke suatu folder. File

Format dalam bentuk Microsoft Excel.



68


4.1.3 Analisa Transformasi sesuai dengan kebutuhan bisnis

Setelah dilakukan analisa kebutuhan informasi dan proses bisnis, serta telah

ditentukannya sumber data yang akan digunakan untuk mengakomodir kebutuhan

bisnis dalam rangka penerapan perhitungan penyisihan cadangan kerugian

penurunan nilai (CKPN) sesuai dengan PSAK 50/55, maka fase berikutnya adalah

menentukan proses transformasi pada proses ETL. Dari fase analisa kebutuhan

informasi dan sumber data yang tersedia, dapat disampaikan bahwa raw data

CKPN tidak tersedia pada sumber data. Oleh karena itu diperlukan fase persiapan

data dengan melakukan transformasi pada data staging pembiayaan untuk

dihitung nilai CKPN-nya berdasarkan analisa kebutuhan bisnis tersebut.

Tabel 4.3 menjelaskan masing-masing proses transformasi dari raw data

pembiayaan sesuai dengan business rule yang disyaratkan dalam penerapan

perhitungan penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) pada Bank

X. Proses transformasi diidentifikasikan mulai dari sumber tabel, rule (filter, join,

data type mapping, formula calculation, agregasi, seleksi, update condition, tabel

temporary, tambahan kolom), kemudian hasil transformasi disimpan pada tabel

tujuan.


69


Tabel 4.3 Tabel sumber tabel dan tujuan tabel serta transformation rule yang melekat sebagai persiapan data CKPN

Data

Source

Tabel Sumber Tabel Tujuan Business Rule dan Deskripsi

ILN dan

JF

- LOAN_DAILY

- FACILITY_DAILY

- CUSTOMER

- MASTER_KURS_DAILY

- MASTER_MIS_BRANCH

Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

- LOAN_DAILY. CNUM = CUSTOMER.CNUM

- LOAN_DAILY. CCY = MASTER_KURS_DAILY.CCY

- LOAN_DAILY.DOWNLOAD_DATE=MASTER_KURS. DOWNLOAD_DATE

- LOAN_DAILY.BRANCH = MASTER_MIS_BRANCH. BRANCH_CODE AND

BSL_FLAG_SYARIAH=’T’

- LOAN_DAILY.BOOKING_FACILITY_NUMBER=

FACILITY_DAILY.FACILITY_NUMBER

- FACILITY_DAILY.ACCOUNT_STATUS = “A”

- LOAN_DAILY.GET_FLAG = '1'

- FACILITY_DAILY.EQV_PLAFOND <>

- LOAN_DAILY.ACCOUNT_STATUS not in ('2','8')

CRD LOAN_CARD_DAILY Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

- DATA_SOURCE='CRD'

- EQV_OUTS >= 0

- GET_FLAG = '1'

CRD FACILITY_CARD_DAILY Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

- FACILITY_CARD_DAILY.CNUM = LOAN_CARD_DAILY.CNUM

- LOAN_CARD_DAILY.FACILITY_NUMBER =

FACILITY_CARD_DAILY.FACILITY_NUMBER

- LOAN_CARD_DAILY.DOWNLOAD_DATE =

FACILITY_CARD_DAILY.DOWNLOAD_DATE


70


Data

Source


MIS CUSTOMER Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

- LOAN_CARD_DAILY.CNUM = CUSTOMER.CNUM

- CUSTOMER.CNUM IS NOT NULL

MIS MASTER_KURS_DAILY Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

- LOAN_CARD_DAILY.CCY = MASTER_KURS_DAILY.CCY

- LOAN_CARD_DAILY.DOWNLOAD_DATE =

MASTER_KURS_DAILY.DOWNLOAD_DATE

MIS MASTER_MIS_BRANCH Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

Kondisi Join Tabel antara Kode Cabang Master dengan Kode Cabang pada Master Data PSAK

LOAN_CARD_DAILY. BRANCH_CODE =

MASTER_MIS_BRANCH.BRANCH_CODE AND

MASTER_MIS_BRANCH.BSL_FLAG_SYARIAH='T'

CRD CCARD_ACCOUNT_DAILY Database : PSAK Tabel :

PSAK_MASTER_ACCOUNT

Transformasi informasi Day Past Due (DPD) menjadi bentuk numeric, karena dari source sistem Kartu Kredit, informasi yang disimpan adalah dalam bentuk cycle penagihan, tidak ada spesifik jumlah hari tunggakan. DAY_PAST_DUE Rule :

CYCLE_DUE = '0' -> 0,CYCLE_DUE = '1' -> 0,CYCLE_DUE = '2' -> 1,CYCLE_DUE

= '3' -> 30,CYCLE_DUE = '4' -> 60,CYCLE_DUE = '5' -> 90,CYCLE_DUE = '6' ->

120,CYCLE_DUE = '7' -> 150,CYCLE_DUE = '8' -> 180,CYCLE_DUE = '9' -> 210,

System

Date

Tanggal Harian Batch System Date Database : PSAK Tabel :

PSAK_PRC_DATE

CURRDATE = SYSTEM DATE

PREVDATE = CURRENTDATE

LAST_DAY(ADD_MONTHS(CURRDATE, -1)

MIS PSAK_MASTER_ACCOUNT_E

DW

PSAK_MASTER_ACCOUNT.

Field : PREVIOUS

_ACCOUNT_NUMBER

Menghilangkan content string “T2KR.” Sehingga hanya mengandung account number saja. Tujuannya adalah untuk mentracking account number karena migrasi dari core banking lama ke core banking baru.


71


Data

Source


PSAK PSAK_EXPECTED_RECOV

_UPLOAD

PSAK_SEGMENT

PSAK_LGD_EXPECTED_RECO

VERY

Field : LGL_RATIO

Formula perhitungan menggunakan metode expected recoveries yaitu membandingkan antara data recoveries yang berasal dari pembayaran debitur dan penjualan asset yang diterima oleh Bank dengan data write off dan Aset yang diambil alih (AYDA) pada masing-masing segmentasi. Perhitungan ini dihitung per level segmentasi. LGL_RATIO = WO + AYDA / (AYDA + RECOVERY) Kondisi :SEGMENT = C09_SEGMENTASI_ACCOUNT

PSAK PSAK_LGD_SETTING PSAK_LGD_EXPECTED_RECO

VERY

Rule untuk mengambil jumlah periode yang akan digunakan dalam perhitungan Loss Given Default dari tabel parameter PSAK_LGD_SETTING.

PSAK PSAK_LGD_EXPECTED_RECO

VERY

PSAK_RECOVERY_MATRIX Mengupdate hasil perhitungan LGD ke Final Tabel dari proses sebelumnya. RECOVERY_RATE = LGD_RATIO

PSAK • PSAK_COLL_SHORTFALL_U

PLOAD

• PSAK_BMI_SEGMENT

PSAK_LGD_COLLATERAL_SH

ORTFALL

Field :

LGL_RATIO

Formula perhitungan LGD menggunakan metode collateral shortfall yaitu membandingkan antara Nilai kredit yang diberikan (Outstanding) dengan nilai Agunan yang ada pada masing-masing segmentasi, dengan syarat bahwa nilai Agunan yang diperhitungkan harus selalu lebih besar dari Nilai Kredit. Perhitungan ini dihitung per level segmentasi. LGL_RATIO = OUTSTANDING – AGUNAN / OUTSTANDING OUTSTANDING – AGUNAN > 0 Kondisi : LGD_SEGMENT = C09_SEGMENTASI_ACCOUNT

PSAK PSAK_LGD_COLLATERAL_SH

ORTFALL

PSAK_RECOVERY_MATRIX

Field : RECOVERY_RATE

Formula dari perhitungan Recovery Rate adalah RECOVERY_RATE = 1 - .LGD_RATIO


72


Data

Source


PSAK PSAK_MASTER_PRODUCT_PA

RAMETER

PSAK_MASTER_ACCOUNT

Field :

- PRODUCT_GROUP - IS_IMPAIRED - IMPAIRED_FLAG

Mengupdate klasifikasi impairment yang akan dihitung menggunakan collective assessment untuk product-product pembiayaan yang terdapat di parameter. - PRODUCT_GROUP = PRD.PRD_GRP, - IS_IMPAIRED = PRD.IS_IMPAIRED, - STAFF_LOAN_FLAG = PRD.STAFF_LOAN_IND, - IMPAIRED_FLAG = CASE

WHEN PMA.IMPAIRED_FLAG = 'I' THEN PMA.IMPAIRED_FLAG ELSE 'C' END

PSAK PSAK_BMI_SEGMENT PSAK_MASTER_ACCOUNT

Field :

- SEGMENT

- PRODUCT_GROUP

Mengupdate segmentasi di master menggunakan segmentasi yang disetting melalui collective group parameter. PRODUCT_GROUP = COLLECTIVE_GROUP_2 Kondisi : SEGMENT = C09_SEGMENTASI_ACCOUNT AND DOWNLOAD_DATE = V_CURRDATE

PSAK PSAK_DPD_MASTER

PSAK_DPD_MASTER_HEADER

PSAK_MASTER_ACCOUNT

Field : DPD_ID

Mengupdate Field DPD_ID di PSAK_MASTER_ACCOUNT untuk semua account pembiyaan dengan klasifikasi grouping menggunakan bucket DPD (Day past due). Dengan kriteria OPTION_GROUPING = ‘DPD’ dan Range Day Past Due antara DPD_START dan DPD_END

PSAK PSAK_DPD_MASTER

PSAK_DPD_MASTER_HEADER

PSAK_MASTER_ACCOUNT

Field : DPD_ID

Mengupdate field DPD_ID untuk semua account pembiyaan dengan klasifikasi grouping menggunakan bucket Kolektibilitas (BI_COLLECTABILITY). Dengan kriteria OPTION_GROUPING = ‘BIC’ dan Range BI_COLLECTABILITY antara DPD_START dan DPD_END yang terdaftar di setting parameter bucket.

PSAK PSAK_DPD_MASTER_HEADER PSAK_ENR Persiapan untuk transformasi menghitung nilai Probability Default, step pertama adalah Transformasi untuk snapshot outstanding per masing-masing periode. Dengan kondisi PSAK_ENR.PRODUCT_GROUP = PSAK_DPD_MASTER_HEADER.PRODUCT_GROUP ANDPSAK_DPD_MASTER_HEADER.METHOD_IMPAIRMENT = 'S00031' AND PSAK_DPD_MASTER_HEADER.CALCULATION_TYPE = 'A';


73


Data

Source


PSAK - PSAK_MASTER_ACCOUNT

- PSAK_MASTER_PRODUCT

_PARAMETER

- PSAK_DPD_MASTER

- PSAK_DPD_MASTER_HEA

DER

PSAK_ENR

Field :

- AMOUNT = TOT_OS

- ACCOUNT = NOA

Menghitung Probability of Defaultdengan metode net flow rate, dimana step awal adalah melakukan snapshot terhadap jumlah outstanding dan jumlah account per masing-masing bucket dan masing-masing segmentasi.

- AMOUNT = OUTSTANDING x EXCHANGE_RATE ACCOUNT = COUNT (NUMBER OF ACCOUNT) Kondisi : PMA.DATA_SOURCE = PRD.DATA_SOURCE AND PMA.PRODUCT_CODE = PRD.PRD_CODE AND PMA.PRODUCT_TYPE = PRD.PRD_TYPE INNER JOIN PSAK_DPD_MASTER DPD_D ON PMA.DPD_ID = DPD_D.DPD_ID AND PMA.PRODUCT_GROUP = DPD_D.PRODUCT_GROUP INNER JOIN PSAK_DPD_MASTER_HEADER DPD_H ON PMA.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP AND DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A' WHERE PMA.DOWNLOAD_DATE = V_CURRDATE AND PMA.OUTSTANDING > 0 AND NVL(PMA.IS_IMPAIRED, ' ') = 'Y' AND NVL(PMA.WRITE_OFF_FLAG, ' ') <> 'Y' --AND NVL(PMA.ACCOUNT_STATUS, ' ') NOT IN ('WO', 'FF') AND NVL(PMA.PRODUCT_GROUP, ' ') <> ' ' AND DPD_H.IA_FLAG = '1'


74


Data

Source


PSAK - PSAK_ENR


DER

TT_ENR_CURR

Field : Amount

Persiapan untuk transformasi menghitung nilai Flow Rate ke tabel temporary untuk periode bulan ini AMOUNT = DPD_H.CALC_METHOD = '1' then ENR.AMOUNT DPD_H.CALC_METHOD = '2' then ENR.ACCOUNT Kondisi Join : ENR.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP WHERE ENR.PERIOD = Periode bulan ini AND DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A';

PSAK - PSAK_ENR


DER

TT_ENR_PREV

Field : Amount

Persiapan untuk transformasi menghitung nilai Flow Rate ke tabel temporary untuk periode bulan sebelumnya. AMOUNT = DPD_H.CALC_METHOD = '1' then ENR.AMOUNT DPD_H.CALC_METHOD = '2' then ENR.ACCOUNT

PSAK - PSAK_ENR


DER

TT_ENR_PREV

Field : Amount

Kondisi Key Join adalah PSAK_DPD_MASTER_HEADER DPD_H ON ENR.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP WHERE ENR.PERIOD = Periode bulan lalu AND DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A';


75


Data

Source


PSAK - PSAK_DPD_MASTER


DER

- TT_ENR_CURR

- TT_ENR_PREV

PSAK_FLOW_RATES

Field :

FLOW_RATES

Mengupdate Field FLOW_RATE di PSAK_FLOW_RATES per masing-masing bucket pembiayaan dengan cara membagi jumlah outstanding di bucket yang lebih rendah ke bucket sebelumnya (outstanding dari bucket 1 ke bucket 2)dengan snapshot Tabel temporary current dan previous. FLOW_RATES = CASEWHEN DPD_D.FLAG_DEFAULT = 'Y' THEN DPD_D.PD_DEFAULT / 100 WHEN NVL(DPD_H.PD_THRESHOLD, 0) <> 0 AND NVL(FL.FLOW_RATES, 0) > NVL(DPD_H.PD_THRESHOLD, 0) / 100 THEN DPD_H.PD_THRESHOLD / 100 Kondisi : ON DPD_D.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP ON DPD_D.PRODUCT_GROUP = FL.PRODUCT_GROUP AND DPD_D.DPD_ID = FL.DPD_ID WHERE DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A'; QUERY KE TABEL TEMPORARY (SELECT A.PRODUCT_GROUP, B.DPD_ID, CASE WHEN NVL(B.AMOUNT, 0) = 0 THEN 1 ELSE A.AMOUNT / B.AMOUNT END AS FLOW_RATES FROM TT_ENR_CURR A INNER JOIN TT_ENR_PREV B ON A.PRODUCT_GROUP = B.PRODUCT_GROUP AND A.DPD_ID = B.DPD_ID + 1


76


Data

Source


- PSAK_FLOW_RATES


DER

PSAK_COMPOUND_FLOW_TO_

LOSS

Field : FLOW_TO_LOSS

Proses untuk menghitung Flow To Lossyang merupakan langkah berikutnya setelah menghitung perbandingan movement flow dari bucket yang lebih tinggi ke lebih rendah. Flow To Loss dihitung dengan merata-ratakan nilai flow rate selama periode data histori (36 bulan) dari bucket tersebut. Perhitungan ini dihitung per segment dan per bucket Misalnya Untuk menghitung Flow To Loss bucket ke-1 pada bulan Jan-2014 maka diambil rata-rata Flow Rate di bucket 1 selama periode 36 bulan yaitu dari bulan Jan-2011 s/d Jan-2013. FLOW_TO_LOSS = AVG(FL.FLOW_RATES) PERIOD BETWEEN Tanggal perhitungan 3 tahun sampai dengan tanggal bulan laporan. GROUP By DPD_ID, PRODUCT_GROUP

- PSAK_COMPOUND_FLOW

_TO_LOSS


DER

- PSAK_DPD_MASTER

- PSAK_RECOVERY_MATRI

X

PSAK_PD

Field : PD

Merupakan Proses terakhir dalam menghitung nilai Probability Default menggunakan metode Net Flow Rate. Dimana Dari angka hasil perhitungan Flow To Loss per masing-masing bucket, kemudian dikalikan sampai dengan bucket terakhir. Misalnya : Flow To Loss Bucket 1 pada periode Jan-2014 untuk segment Auto adalah 14.36%, bucket ke-2= 14.81%, bucket ke-3 = 39.06%, bucket ke-4 = 65.17%, dan bucket ke-5 = 100%. Maka Perhitungan Nilai PD untuk bucket ke-1 adalah 14.36% x 14.81% x 39.06% x 65.17% x 100% = 0.54%. Sedangkan untuk PD bucket ke-2 adalah perkalian dari bucket ke-2 sampai dengan bucket ke-5 yaitu 14.81% x 39.06% x 65.17% x 100% = 3.77% dan seterusnya sampai dengan perhitungan PD maximum Bucket..


77


Data

Source


- PD = CASE WHEN NVL(DPD_D.FLAG_DEFAULT, '0') = 'Y' THEN DPD_D.PD_DEFAULT / 100 ELSE CASE COUNT(CASE SIGN(FTL.FLOW_TO_LOSS) WHEN 0 THEN 1 ELSE NULL END) WHEN 0 THEN -- NO ZEROES: PROCEED NORMALLY CASE MOD(SUM(CASE SIGN(FTL.FLOW_TO_LOSS) WHEN -1 THEN 1 ELSE 0 END), 2) WHEN 1 THEN -1 ELSE END EXP(SUM(LN(ABS(CASE FTL.FLOW_TO_LOSS WHEN 0 THEN NULL ELSE FTL.FLOW_TO_LOSS END)))) ELSE 0 END END AS DELIQUENCY_RATE Kondisi : PRODUCT_GROUP =.PRODUCT_GROUP PRODUCT_GROUP = PRODUCT_GROUP DPD_D.DPD_ID <= FTL.DPD_ID PERIOD = MAT.PERIOD AND FTL.PRODUCT_GROUP = MAT.PRODUCT_GROUP WHERE FTL.PERIOD = V_PERIOD AND DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A' GROUP BY DPD_D.DPD_ID, FTL.PRODUCT_GROUP, FTL.PERIOD, MAT.RECOVERY_RATE, DPD_D.FLAG_DEFAULT, DPD_D.PD_DEFAULT;

PSAK PSAK_ENR PSAK_PD

Field : OS

OS = PSAK_ENR.AMOUNT; Kondisi : PERIOD = PERIOD PRODUCT_GROUP = PRODUCT_GROUP DPD_ID = DPD_ID PSAK_PD.PERIOD = ‘Currentdate’


78


4.2 Perancangan Arsitektur DataMart

Sebelum dilakukan perancangan permodelan datamart, maka diperlukan analisa

perancangan arsitektur datamart yang akan digunakan. Jenis arsitektur dalam

perancangan datamart PSAK 50/55 menggunakan konsep Independent Data Mart

dimana menggunakan layer data staging untuk mengintegrasi data dari berbagai

sumber data yang berbeda yang terkait dengan pembiayaan pada Bank X. Dari

data staging kemudian dilakukan ETL ke datamart PSAK 50/55 .

Berdasarkan alternatif arsitektur datawarehouse menurut Inmon dan Kimball,

dalam perancangan arsitektur untuk implementasi penerapan datamart PSAK

khususnya dalam ruang lingkup monitoring dan pelaporan cadangan kerugian

penurunan nilai (CKPN) dapat disampaikan perbandingan arsitekturnya sebagai

berikut. Tabel 4.4 mengenai analisa perbandingan arsitektur Inmon dan Kimbal

dalam merancang datamart PSAK 50/55

Tabel 4.4 Tabel Analisa Perbandingan Arsitektur Inmon dan Kimball serta

keterangan dalam arsitektur datamart PSAK 50/55 Kriteria Inmon Kimball Kondisi Penelitian saat ini

Overall

Approach

Top-Down Bottom-up DesainData Mart menggunakan Dimensional

Modeling yaitu Tabel Fakta dan Tabel Dimensi

yang dibuat berdasarkan kebutuhan laporan

yang dibutuhkan spesifik terkait dengan

Cadangan Kerugian Penurunan Nilai dan

Pembiayaan pada Bank X. Tabel Fakta

Pembiayaan dengan pengukuran

outstandingyang diberikan, dengan Dimension

antara proses yang satu dengan yang lainnya

seperti Dimensi Flag Impairment, Dimensi

Segment, Dimensi Produk, Dimensi Cabang,

Dimensi Kolektibilitas dan Dimensi Jatuh

Tempo Pembiayaan (Maturity).


79


Kriteria Inmon Kimball Kondisi Penelitian saat ini

Data Orientation Subject or

Data Driven

Process

Oriented

Pendekatan dimulai dari pemahaman proses

bisnis dan aturan pembentukan nilai

penyisihan cadangan kerugian penurunan nilai

(CKPN) dari setiap pembiayaan pada Bank X

dari setiap aktivitas pencairan kredit kepada

nasabah. Proses akan menentukan pengukuran

(measurement) pada tabel Fakta dan dimensi

yang terkait dengan kebutuhan pelaporan.

Struktur Data Non metric

data that

will be

applied to

meet

multiple and

varied

information

needs

Business

metrics,

performan

ce

measures

and

scorecards

Sudah terdapat pengukuran akibat perhitungan

CKPN menurut standar PSAK 50/55. Data

sudah dikonsolidasikan menjadi data yang

terstruktur sesuai dengan kebutuhan bisnis.

Persistency of

Data

High rate of

change from

source

systems

Sumber

data

relative

stabil

Sumber Data bersifat fixed atau final diambil

dari core bankingyang relatif jarang berubah.

Apabila terdapat perubahan dari sisi core

banking akan dilakukan remapping ulang di

dari sumber data ke data staging, kemudian ke

data model Datamart PSAK.

Data Integration

Requirements

Enterprise

Wide

integration

Individual

business

area

Integrasi yang dilakukan adalah dari semua

sumber data dari core banking yang terkait

dengan seluruh data pembiayaan, tetapi tidak

termasuk data-data yang terkait dengan data

Dana Pihak ketiga (Tabungan, Deposito),

Treasury, Liabilities dan Surat Berharga.

Time to

Delivery

Organizatio

n’s

requirements

allow for

longer start

up time

Need for

the first

data

warehouse

applicant

is urgent

Sehubungan dengan Surat Edaran dari Bank

Indonesia, maka implementasi Datamart PSAK

ini akan diimplementasikan maksimum dalam

waktu 6 bulan dan wajib diimplementasikan

pada tahun 2014 untuk grup Bank Syariah.


80


Kriteria Inmon Kimball Kondisi Penelitian saat ini Kemudahan

Akses

Pengguna/Siapa

Penggunanya

Low/IT High/End

User –

User dari

perwakilan

bisnis

Direct End User (Finance&Accounting, Risk

Management) akan senantiasa langsung

menggunakan data pelaporan ini untuk

kepentingan regulator (Bank Indonesia),

laporan antar cabang dan analisis profit and

loss (rugi laba) dari setiap cabang. Tujuannya

agar di bulan bulan yang akan datang dan

tahun yang akan datang dapat memberikan

input terhadap penyusunan strategi

pembiayaan dan manajemen risiko di Bank X.

Time Frame Kontinyu

dan Diskrit

Slowly

Changing

Dimension

(SCD)

Type I,

Type II,

Type III

Data-data yang digunakan bervariasi, misalnya

: dimensi segmentasi pembiayaan, dimensi

cabang, dimensi maturity profile, dimensi

kolektif grup merupakan SCD Type 2,

dimensi waktu, dimensi kolektibilitas, dimensi

flag Impairment merupakan SCD Type 0,

sedangkan dimensi customer merupakan SCD

Type I.

Nature of the

organization’s

decision support

requirements

Strategic Tactical Strategic, karena terkait dengan dampak dari

laporan keuangan suatu enterprise Bank dan

merupakan syarat compliance dari regulator.

Berdasarkan perbandingan karakteristik permodelan data warehouse Inmon dan

Kimball, arsitektur dengan model Kimball lebih tepat digunakan dalam

perancangan arsitektur data mart PSAK 50/55.

Arsitektur data mart PSAK 50/55 terdiri dari 4 bagian yaitu Data Source Layer,

Data Staging Layer, ETL Layer, dan User Access Layer yang dapat dilihat pada

Gambar 4.2


81


Gambar 4.2 Hasil Rancangan Arsitektur Data Mart PSAK 50/55

Keterangan dari Gambar4.2:

a. Data Source Layer ; Sumber data yang digunakan untuk relational database

PSAK dan reporting data mart PSAK 50/55 diperoleh dari Online Transaction

Processing(OLTP) yang tersimpan dalam operasional database sistem

pembiayaan, yang terdiri dari Host AS400, Credit Card, Joint Finance dan

sumber data yang berasal dari manual input oleh pengguna yaitu berbentuk

flat file dalam format Excel ataupun Text Files. Sumber data manual input ini

tidak tersedia didalam sistem OLTP Bank X yang terdiri dari user parameter

sesuai dengan persyaratan aturan PSAK 50/55, dan data-data yang tidak

tersedia pada masing-masing core banking system seperti data target CKPN,

data write off dan data recovery. Prosesnya berasal dari tabel database

operasional yang diekstraksi ke dalam bentuk teks file dan kemudian di-load

keareadata staging.

b. Staging Area Layer; merupakan proses ektraksi dan tempat penampungan

data dari masing-masing source system dengan struktur data yang sama

dengan asalnya. Ekstraksi masing-masing sumber data tersebut dalam bentuk

text files, kemudian dari text files akan dimuat ke tabel penampung dengan


82


format text untuk semua data type yang ada didalamnya. Hal ini dimaksudkan

untuk memastikan konsistensi dan integritas data untuk seluruh sumber data

dapat termuat dengan sempurna. Sumber data tersebut berasal dari Core

Banking Database (Card, iLoan, JF, Transactional), MIS Database yang

menampung data Customer, ataupun data-data manual berasal dari input

pengguna dalam format Flat Files dengan template tertentu. Tempat Data

staging ini akan diletakkan ke masing-masing tabel penampung seperti tabel :

Loan Daily, Customer, Kurs Daily, Card Daily, Transaction Daily, dan lain-

lain.Selanjutnya dilakukan mapping dan transformasi tipe data yang sesuai

dengan tipe data masing-masing tabel di PSAK.

c. ETL Process Layer ; Pada proses ETL akan dilakukan proses Identify,

Capture, Map, Cleanse, Transform dan Load, dari raw data ke business logic

area. Proses loading data dari sumber data ke staging area dan dari staging

area ke downstream datamart. Sebagai bagian dari proses ETL, pengecekan

ketersediaan system, pengecekan jumlah dan pengecekan lainnya akan

dilakukan untuk memastikan jumlah data yang disediakan oleh sumber data

berhasil diproses. Dari staging layer, yang sumbernya adalah data-data dari 6

sumber database operasional masing-masing sistem pembiayaan (Card, ILN,

JF, Transactional) ditambah database MIS yang menampung data Customer,

serta manual input proses data (data writeoff, recovery, data override

impairment, data forecast dan user parameter PSAK 50/55) untuk

ditransformasi ke dalam relational database PSAK sampai dengan semua

proses bisnis yang diisyaratkan pada bagian analisa data dan kebutuhan

informasi selesai ditransformasi. Setelah proses perhitungan final, maka

seluruh data dari relational database PSAK akan di-load melalui proses ETL

ke Datamart PSAK 50/55 dengan model dimensional. Penjelasan dari proses

ETL sebagai berikut:

1. Ekstraksi dan Mapping ; Proses ETL dari data source berupa ekstraksi ke

text file dan dari teks file ke relational database PSAK Pada bagian ini

dari data staging dilakukan Map ke Model Data relational database

PSAK sesuai dengan kebutuhan PSAK yaitu ke tabel



83


2. Transformasi ke Model Data PSAK; merupakan model data yang

dibutuhkan untuk menghasilkan informasi Cadangan Kerugian Penurunan

Nilai (CKPN) sebagaimana dipersyaratkan oleh regulator Bank Indonesia

dan Ikatan Akuntan Indonesia menurut serangkaian business rule, antara

lain : proses segmentasi, klasifikasi impairment, perhitungan Probability

Default (PD) dan Loss Given Default (LGD), dan finalnya adalah proses

perhitungan CKPN Individual dan CKPN Kolektif. Bentuk database disini

adalah bersifat database relational. Database tersebut merupakan area

tempat penyimpanan data yang sudah dilakukan transformasi dan

standarisasi. Proses transformasi dari langkah pertama dan langkah kedua

merupakan proses persiapan data CKPN.

3. Transformasi sumber data yang tersedia ke tabel dimensi dan selanjutnya

adalah transformasi sumber data yang akan diload ke tabel fakta

disesuaikan dengan key pada tabel dimensi.

4. Load ke Datamart PSAK 50/55; Datamart untuk penyajian sangat

tergantung dengan proses sebelumnya berupa proses persiapan data

sebagai sumber data CKPN dan Pembiayaan serta proses transformasi data

sebelum di-load ke tabel fakta dengan menyesuaikan key pada tabel

dimensi. Data mart PSAK 50/55 ini dibangun berdasarkan kebutuhan

pelaporan dan analisa dari unit bisnis Divisi Akuntansi dan Keuangan serta

Divisi Manajemen Risiko dengan menggunakan teknik dimensional data

model menurut Kimball. Dari sumber relational database PSAK termasuk

hasil transformasi data yang sudah dilakukan, kemudian di-load ke

datamart PSAK yang terdiri dari tabel dimensi dan tabel fakta seuai

dengan keperluan pelaporan dan analisa CKPN sesuai dengan PSAK 50/55

di Bank X. Semua sumber tabel yang sudah di load ke datamart PSAK

berupa informasi final yang akan digunakan dalam kebutuhan pelaporan

dan analisa, yang mana merupakan area utama tempat penyimpanan data

yang bersifat final dan tidak dapat di-update berdasarkan subyek area

yang sudah dilakukan proses normalisasi dengan model 3NF.

User Access Layer. Pada layer ini terdiri dari Reporting Layer dan User

Access, dimana berisi objek yang digunakan untuk kebutuhan pelaporan,


84


query dan analisis. Business Intelligence data mart dibangun dengan konsep

multi dimensional, yang terdiri dari tabel fakta dan tabel dimensi. Hasil akhir

dari pembentukan datamart akan digunakan oleh pengguna melalui aplikasi

business intelligence dan aplikasi reporting. Beberapa alternatif reporting

tools yang ada seperti Cognos Business Intelligence, Cognos Insight,

Microsoft Analytical services dan Reporting Services, Oracle Business

Intelligence, dan lain sebagainya dapat digunakan sebagai alternatif oleh

pengguna aplikasi dalam bentuk On Line Analytical Processing (OLAP) dan

dashboard untuk menampilkan informasi dan analisa informasi yang

dibutuhkan.

4.3 Perancangan Permodelan Data Warehouse

Pada bagian ini akan dijelaskan mengenai tahap-tahap permodelan datamart

menurut Ralph R Kimball dengan 9 langkah permodelan datamart.

4.3.1 Pemilihan Proses Bisnis (Choosing the process)

Proses bisnis yang dipilih pada penelitian ini adalah proses bisnis pembiayaan

atau kredit dan proses bisnis pembentukan Cadangan Kerugian Penurunan Nilai

sesuai dengan PSAK 50/55.

1. Proses bisnis Pembiayaan

Pembiayaan adalah penyediaan uang atau tagihan berdasarkan persetujuan dan

pinjam meminjam antara pihak lain yang mewajibkan pihak yang meminjam

untuk melunasi hutangnya setelah jangka waktu tertentu dengan perhitungan

bunganya. Proses Bisnis yang dipilih mencakup semua pembiayaan dengan

perjanjian yang termasuk ke semua jenis kredit, baik kredit investasi, modal kerja,

maupun konsumsi yang diawali dengan perjanjian terlebih dahulu misalnya;

Kredit Konsumen, Kredit Modal Kerja, Kredit Pemilikan Rumah, Kredit

Kendaraan Bermotor, Kredit Multiguna, Kredit Sindikasi, Kredit Korporasi,

Kredit Mikro, Pembiayaan Haji dan Umroh dan lain sebagainya.


85


Dimulai dari penandatangan perjanjian kredit, kemudian pencatatan biaya notaris,

asuransi, appraisal independen, Materai, dan lain-lain. Pencatatan penyediaan

plafon kredit (dicatat pada Off Balance Sheet), pencatatan penerimaan Provisi,

Komitmen Fee, Management Fee, dan Administrasi Pencatatan Amortisasi

Provisi, dan Fee lainnya, Pencataan Penggunaan Plafon (Reversal Off Balance

Sheet) sampai dengan Pencatatan Pencairan Kredit. Setelah proses pencarian

kredit merupakan dimulainya akad pembiayaan sampai dengan berakhirnya akad

pembiayaan. Berakhirnya akad pembiayaan ini dapat disebabkan karenalunas

sesuai jatuh tempo pembiayaan, dilakukan pelunasan dipercepat, atau dihapus

buku karena tidak mampu memenuhi kewajiban. Proses yang ada di dalamnya

yaitu pencatatan bunga harian, pencatatan pembayaran angsuran pokok dan

bunga, pencatatan pembayaran tunggakan bunga dan tunggakan pokok (jika ada),

proses restrukturisasi kredit, pencatatan pelunasan dipercepat atau pada saat jatuh

tempo, pencatatan hapus buku / hapus tagih, pencatatan pembayaran setelah hapus

buku / hapus tagih.

Pertumbuhan pembiayaan menjadi tolak ukur bagi manajemen Bank bank sebagai

pencapaian kinerja penyaluran kredit di pasar di semua segmentasi serta didukung

dengan kualitas pembiayaan yang baik yang diindikasikan dengan Non Perfoming

Loan Ratio yang cukup kecil.

2. Proses bisnis Pembentukan Cadangan Kerugian Penurunan Nilai pada produk

pembiayaan

Penyisihan kerugian kredit (Loan-Loss Provisioning) adalah penyisihan

(provisioning) kerugian atas portfolio kredit dan pendanaannya yang mengalami

penurunan nilai ekonomi. Nilai ekonomi dari portfolio kredit dapat naik atau

turun disebabkan karena adanya perubahan dengan kualitas kredit (dicerminkan

dengan rating kolektibilitas Bank Indonesia ) yaitu jika terjadi masalah terhadap

itikad baik (willingness to pay) dan kemampuan debitur untuk melunasi kredit

beserta pinjamannya (ability to pay).

Pembentukan CKPN ini didasarkan atas klasifikasi CKPN, pengelompokan

karakteristik kredit berdasarkan profil risiko pembiayaan (collective group),


86


penentuan metode statistika dalam menghitung PD dan LGD, perhitungan PD,

perhitungan LGD, perhitungan CKPN secara kolektif yaitu dengan mengalikan

PD x LGD x Outstanding. Sedangkan perhitungan CKPN individual dengan

menggunakan estimasi arus kas yang dapat terpulihkan, penentuan impaired loan

ratio, dan penentuan target pembentukan CKPN.

4.3.2 Pemilihan Grain (Choosing the Grain)

Grain atau granularity adalah informasi yang akan direpresentasikan oleh record

dari tabel fakta. Grain merupakan data detail dari data di tabel Fakta yang dapat

dianalisis, yaitu bagaimana mendeskripsikan single row di tabel fakta di level

yang paling kecil sesuai dengan kebutuhan analisa.

1. Pembiayaan

- Cabang yang memiliki kontribusi pembiayaan paling tinggi di suatu

periode

- Segmentasi yang memiliki kontribusi pembiayaan paling tinggi di suatu

periode

- Produk dan segmentasi mana saja yang memiliki kontribusi skema

maturity profile / tingkat pembiayaan berdasarkan lamanya umur jatuh

tempo

- Produk pembiayaan mana yang paling banyak diminati

- Produk pembiayaan yang paling diminati untuk mata uang valas

- Produk / segment / cabang mana saja yang mana pembiayaannya

mengalami mengalami tingkat non performing loan yang tinggi. Non

Performing Loan yaitu pembiayaan yang mempunyai nilai kolektibilitas

3,4,dan 5

- Rasio Non perfoming loan terhadap total pembiayaan per cabang dalam

periode tertentu.

- Distribusi pembiayaan yang mengalami perubahan kolektibilitas (ke lebih

baik atau lebih buruk atau pembiayaan tersebut matured) yang paling

besar pada bulan sebelumnya per masing-masing produk, segment,

currency, cabang.


87


- Distribusi pembiayaan yang perubahan kolektibilitasnya tetap (tidak

berubah) per masing-masing produk, segment, currency, cabang

- Distribusi pembiayaan yang perubahan kolektibilitasnya tetap (tidak

berubah) per masing-masing produk, segment, currency, cabang

Dari kebutuhan analisa diatas, maka level granularitas untuk bisnis proses

pembiayaan di level cabang, segment, produk, currency, movement kolektibilitas,

maturity profile code, dan bi kolektibilitas. Namun untuk membentuknya harus

dibuat pada level account number, mengingat kebutuhan analisa dari maturity

profile yang dilihat per level account number, dan kebutuhan analisa dari

perubahan kolektibilitas

2. Penyisihan Cadangan Kerugian Penurunan Nilai

- Nilai CKPN Individual dan CKPN Kolektif per customer number

- Nilai CKPN Kolektif yang memberikan kontribusi terbesar per collective

impairment group pada periode waktu tertentu.

- Nilai Persentase PD (Probability Default) pada masing-masing collective

impairment group, kolektibilitas dan periode waktu.

- Nilai Persentase LGD (Loss Given Default) untuk setiap collective

impairment group, kolektibilitas dan periode waktu.

- Snapshot dari cabang dengan Movement Charged CKPN terbesar pada

periode waktu tertentu.

- Snapshot dari cabang dengan Movement Released CKPN terbesar pada

periode waktu tertentu.

- Snapshot dari cabang yang memiliki kontribusi CKPN berdasarkan

impairment flag (individual dan kolektif) terbesar

- Cabang mana yang memiliki Impairment Loan Ratio (total CKPN / total

pembiayaan) terbesar

- Cabang mana yang mempunyai nilai variance CKPN actual dan CKPN

forecast terbesar. Nilai Variance didapat dari prekalkulasi Forecast CKPN

dikurangi CKPN actual

- Cabang mana yang mempunyai selisih perbandingan provisi menggunakan

PPAP dan CKPN


88


Dari kebutuhan analisa diatas, maka level granularitas untuk bisnis proses

Penyisihan Cadangan Kerugian Penurunan Nilai (CKPN) berada pada level

customer_number (group by customer_number). Tabel 4.5 merupakan tabel

pemilihan grain atas masing-masing informasi yang dapat dianalisa

Tabel 4. 5 Tabel pemilihan grain atas informasi yang dapat dianalisa Granularitas Keterangan

Nilai Pembiayaan

(outstanding)

Nilai pembiayaan (outstanding) didapat dari summarize dari nilai

outstanding dari setiap produk / segmentasi pada periode tertentu

(bulan, kuartal, tahun) untuk masing-masing currency/mata uang

Nilai Plafond

Pembiayaan/kredit (plafond)

Nilai plafond atau batas kredit tertinggi yang dapat diberikan oleh

Bank terhadap masing-masing debitur, didapat dari summarize

nilai plafond dari setiap produk, segment, mata uang pada periode

tertentu (bulan, kuartal, tahun)

Nilai Non Performing Loan Nilai Outstanding yang mengalami kriteria non performing loan

yaitu dengan kondisi nilai kolektibilitas di 3,4, 5 yang didapat dari

summarize setiap cabang, produk dan segmentasi pembiayaan per

masing-masing currency/mata uang pada setiap periode

Nilai Rasio Non Perfoming

Loan

Nilai Rasio Non Performing Loan didapatkan dari pembagian

antara summary pembiayaan yang kolektibilitasnya mulai dari

kolektibilitas 3, 4, 5 dibagi dengan total pembiayaan per masing-

masing cabang pada periode tertentu (bulan, kuartal, tahun)

Nilai CKPN Nilai Cadangan Kerugian Penurunan Nilai didapat dari summarize

nilai CKPN individual dan CKPN kolektif per masing-masing

account pada periode tertentu (bulan, quartal, tahun)

Nilai CKPN Individual Nilai Cadangan Kerugian Penurunan Nilai didapat dari summarize

nilai ckpn individual per masing-masing account pada periode

tertentu (bulan, quartal, tahun)

Nilai CKPN Kolektif Nilai Cadangan Kerugian Penurunan Nilai didapat dari summarize

nilai ckpn kolektif per masing-masing account pada periode

tertentu (bulan, quartal, tahun)

Nilai Movement (Charged)

CKPN

Nilai movement charged CKPN didapat dari summarize selisih

nilai CKPN bulan pelaporan dikurangi dengan nilai CKPN bulan

sebelumnya per masing-masing nomor pembiyaaan dengan kondisi

nilai CKPN bulan pelaporan > nilai CKPN bulan sebelumnya


89


Granularitas Keterangan

Nilai Movement (Released)

CKPN

Nilai movement charged CKPN didapat dari summarize selisih

nilai CKPN bulan pelaporan dikurangi dengan nilai CKPN bulan

sebelumnya per masing-masing nomor pembiyaaan dengan kondisi

nilai CKPN bulan pelaporan < nilai CKPN bulan sebelumnya

Nilai Rasio Impaired Loan Nilai rasio Impaired Loan didapat dari summarize pembagian nilai

total CKPN (Individual dan Kolektif) dibagi dengan nilai

pembiayaan per masing-masing produk pada periode tertentu

(bulan, quartal, tahun)

Nilai Persentase PD

(Probability Default)

Nilai persentase PD probability default yang didapat dari proses

perhitungan atau transformasi dari hasil segmentasi collective

group pada setiap periode. Nilai persentase PD di level collective

group dan kolektibilitas untuk setiap periode tertentu

Nilai Persentase LGD (Loss

Given Default)

Nilai persentase LGD Loss Given Default didapat dari hasil

segmentasi collective group pada setiap periode. Nilai Persentase

LGD ini di level collective group bukan di level account

pembiayaan. Granularitasnya di collective group.

Nilai Persentase PD x LGD

atau Expected Loss Rate

Nilai persentase PD dikalikan dengan nilai persentase LGD untuk

masing-masing collective group dan kolektibilitas pada setiap

periode tertentu

Nilai Maximum BI

Kolektibilitas

Nilai maksimum BI Kolektibilitas didapat dari summarize nilai

maksimum dari kolektibilitas per masing-masing customer number

Nilai Variance Forecast

CKPN dengan Actual

Nilai variance forecast CKPN dengan Aktual CKPN ini didapat

dari summarize selisih Forecast CKPN dan CKPN actual pada

setiap cabang dan periode tertentu (bulan, kuartal, tahun).

Nilai PPAP (Penyisihan

Penghapusan Aktiva

Produktif)

Nilai PPAP di dapat dari summarize nilai PPAP pada setiap cabang

dan periode tertentu (bulan, kuartal, tahun)

4.3.3 Identifikasi dan Penyesuaian Dimensi (Identifiying and Conforming the

Dimensions)

Berikut ditampilkan hubungan dimensi dengan grain dari fakta dalam bentuk

matriks :


90


1. Pembiayaan

Setelah dilakukan pemilihan proses bisnis dan pemilihan grain, maka fase ini

akan menjelaskan identifikasi dan penyesuaian dimensi dari setiap grain yang

sudah dipilih. Tabel 4.6 menjelaskan hubungan antara grain dan kemungkinan

dimensi pada bisnis proses pembiayaan.

Tabel 4. 6 Tabel Grain dan Dimensi pada Pembiayaan

2. Pembentukan Cadangan Kerugian Penurunan Nilai

Tabel 4.7 menjelaskan hubungan antara masing-masing grain dan kemungkinan

dimensi pada bisnis proses pembentukan CKPN.

Tabel 4.7 Tabel Grain dan Dimensi pada Pembentukan CKPN


91


Daftar tabel dimensi yang berkaitan dengan datamart PSAK dapat dilihat pada

Tabel 4.8.

Tabel 4.8 Tabel Identifikasi Dimensi

Dimensi Keterangan

Period Menyimpan informasi keterangan waktu harian, bulanan,

quarter, semester dan tahunan.

Segment Menyimpan informasi mengenai segmentasi pembiayaan untuk

semua jenis kredit.

Collective Group Menyimpan informasi parameter konfigurasi group dari kredit

yang mempunyai karakteristik kredit yang homogen untuk

proses perhitungan PD dan LGD. Didasarkan atas segment dari

pembiayaan.

Currency Menyimpan informasi mengenai jenis-jenis mata uang yang ada

dengan hirarki valas, non valas, currency code dan deskripsi

dari mata uang

Branch Menyimpan informasi cabang dari Bank X termasuk regional

area terkait

Kolektibilitas Menyimpan informasi kolektibilitas Bank Indonesia sebagai

profil risiko setiap debitur (1, 2,3,4, 5)

Produk Menyimpan informasi mengenai produk pembiayaan yang ada

di Bank X untuk seluruh akad pembiayaan

Movement Collect Menyimpan informasi pergerakan atau perubahan kolektibilitas

Maturity Profile Bucket Menyimpan informasi mengenai range atau sebaran kelompok

jatuh tempo pembiyaaan

Impairment Flag Menyimpan informasi klasifikasi impairment yaitu Collective

Assessment dan Individual Assessment

Customer Meyimpan informasi mengenai debitur


92


4.3.4 Pemilihan Fakta (Choosing the Fact)

Di dalam memilih Fakta sebaiknya fakta merupakan data dapat dihitung, dimana

dapat ditampilkan dalam bentuk laporan, grafik, atau berbagai macam diagram.

Biasanya nilai yang dapat diukur terkait dengan pengukuran dari kinerja bisnis.

Berikut ini adalah fakta dalam penerapan datamart

1. Fakta Pembiayaan: Fakta yang berkaitan dengan analisis portfolio

pembiayaan dari Bank X dari sisi total plafond kredit yang diberikan, total

pembiayaan yang diberikan, total pembiayaan yang mengalami non

perfoming, ratio non performing loan dibandingkan pembiayaan yang paling

tinggi. Fakta pembiayaan ini dikelompokkan berdasarkan cabang, produk,

currency, segmentasi, BI kolektabilitas, kelompok pembiayaan yang akan

jatuh tempo, dan pergerakan kolektibilitas untuk setiap periode waktu.

2. Fakta Cadangan Kerugian Penurunan Nilai: Fakta yang berkaitan dengan

analisa pembentukan cadangan kerugian penurunan nilai pada portfolio kredit

pembiayaan di Bank X, seperti Customer mana yang memberikan top – n

kontribusi CKPN Individual, Segmentasi mana yang memberikan CKPN

terbesar dalam setiap bulan, Ratio Impaired Loan dibadingkan dengan total

pembiayaan yang paling tinggi dari setiap cabang, Cabang mana yang

memiliki variance forecast CKPN dan Actual CKPN yang paling tinggi.

Pergerakan mutasi (charged/released) CKPN setiap bulan. Nilai Probability

Default Rate, Loss Given Default Rate dan Expected Loss Rate per masing-

masing collective group of impairment.

4.3.5 Penyimpanan Pre-Calculation pada Tabel Fakta (Storing Pre-

Calculation in the Fact Tabel)

Ketika Fakta dipilih, maka setiap fakta tersebut harus diuji apakah ada fakta yang

dapat digunakan sebagai kalkulasi awal, yang kemudian disimpan pada tabel

fakta. Berikut ini merupakan kalkulasi awal yang dapat dilakukan, untuk

selanjutnya disimpan dalam tabel fakta:


93


a. FACT_LOAN

- SumOfOutstanding : SUM(Outstanding), disimpan ke dalam tabel fakta pada

field Outstanding

- CountOfNumberOfAccount : COUNT(Account_Number) disimpan ke dalam

tabel fakta pada field NumberOfAccount.

- SumOfPlafond : SUM(Plafond), disimpan ke dalam tabel fakta pada field

Plafond.

- SumOfNonPerfomingLoan : SUM(NonPerformedLoan) dengan kondisi field

BI_Collectability in (3, 4, 5) di kelompokkan berdasarkan cabang. Kemudian

disimpan ke dalam tabel fakta pada field NonPerfomingLoan.

- SumOfRatioNPL : SUM(NonPerfomedLoan)/SUM(Outstanding) di

kelompokkan berdasarkan cabang, kemudian disimpan ke dalam tabel fakta

field NPL_RATIO

- Konversi perbedaan tanggal jatuh tempo (field : LOAN_DUE_DATE) ke

tanggal pelaporan (DOWNLOAD_DATE) dengan menggunakan formula date

difference antara tanggal pelaporan dan tanggal jatuh tempo

DATEDIFF(DAY, DOWNLOAD_DATE,LOAN_DUE_DATE) kemudian di-

look up ke tabel dimension DIM_MATURITYPROFILE field

MATURITYPROFILE_SK untuk range mapping result dari hasil kalkulasi

day difference.

- Transformasi pergerakan kolektibilitas per masing-masing account number

dari bulan lalu ke bulan pelaporan dengan menggabungkan nilai kolektibilitas

bulan lalu ditambahkan dengan character ‘-‘ lalu nilai kolektibilitas bulan ini.

Script transformasi : CONVERT(varchar(1),A.bi_collectability) + '-' +

CONVERT(varchar(1),B.bi_collectability) . Hasil transformasi itu dilookup ke

tabel dimensi DIM_COLLECTIBILITY_MOVEMENT field

COLLECTMOVEMENT_DESC.

Semua data yang dihitung dikelompokkan (group by) berdasarkan tanggal

pelaporan (download_date), akad_code, segment, currency, area_code,

main_branch_code, branch_code, bi_collectability, product_code,

collectmovement_sk, maturityprofile_code.


94


b. FACT_CKPN

- Jumlah Account Number per masing-masing Customer Number :

Count(Account_Number) grouped by customer_number

- SumOfCKPNForecast : SUM(CKPN_Forecast). Granularitas Data CKPN

Forecast adalah di level Cabang. Untuk melakukan breakdown ke level

Customer maka di-prorate berdasarkan outstanding dari setiap customer di

suatu cabang. CKPN_Forecast per masing-masing customer number =

CKPN_Forecast * Oustanding / SUM(Outstanding) group by customer

number.

- VarianceCKPNForecast_Aktual. Nilai variance didapat dari prekalkulasi

CKPN_Forecast – CKPN di level customer number.

- Percentage of ExpectedLossModel : PD Percentage x LGD Percentage per

collective impairment group

- SumOfCKPNIndividual : SUM(IIP_AMOUNT). Penjumlahan agregasi dari

nilai CKPN Individual.

- SumOfCKPNKolektif : SUM(PIP_AMOUNT). Penjumlahan agregasi dari

nilai CKPN Kolektif

- SumOfCKPNTotal : SUM(CKPN). Penjumlahan agregasi dari nilai CKPN

Individual ditambah dengan nilai CKPN kolektif.

- SumOfMovementCharged: sum(CHARGE). Charged didapat dengan

mengurangi Total CKPN bulan pelaporan (month-n) dikurangi Total CKPN

bulan lalu (month-n-1) per customer number.

- SumOfMovementReleased : sum(WRITEBACK). Apabila nilai CKPN bulan

ini lebih kecil daripada CKPN bulan lalu, termasuk didalamnya akun

pembiayaan yang sudah hilang/closed. Nilai defaultnya dalam bentuk bilangan

negatif yang didapat dari hasil kalkulasi nilai total CKPN bulan ini dikurangi

dengan nilai total CKPN bulan lalu.

- SumOfRatioImpairmentLoan : Total CKPN / Total Outstanding per cabang

- PPAP didapat dengan mengalikan persentase tertentu dengan outstanding

dalam mata uang rupiah, sesuai dengan nilai dari masing-masing kolektibilitas

per customer number. PPAP dengan kolektibilitas 1 adalah nilai outstanding

dikalikan dengan 1%, jika kolektibilitas 2, maka nilai outstanding dikalikan


95


dengan 5%, jika kolektibilitas 3 maka nilai outstanding dikalikan dengan 15%,

jika kolektibilitas 4 maka nilai outstanding dikalikan dengan 50% dan jika

kolektibilitas 5 maka nilai outstanding dikalikan dengan 100%.

- maxOfBICollectability: max(BI_COLLECTABILITY) adalah nilai

maksimum kolektibilitas per masing-masing customer_number.

4.3.6 Melengkapi Tabel Dimensi (Rounding Out the Dimension Tabel)

Menambahkan sebanyak mungkin property atribut deskripsi teks dan tabel

dimensi. Deskripsi tersebut harus intuitif dan dapat dimengerti oleh pengguna.

Berikut ini adalah hal-hal yang dilakukan pada tahapan ini :

a. Tabel Rounding Out Dimension. Tabel 4.9 menjelaskan penggunaan dimensi,

informasi, deskripsi dan hirarki dari informasi.

Tabel 4.9 Tabel Penjelasan Dimensi

No Dimensi Field Deskripsi Hierarki 1. Period Date

Month

Quarter

Semester

Year

Menyimpan informasi

keterangan waktu harian,

bulanan, quarter, semester dan

tahunan.

Year

Semester

Quarter

Month

Date

2. Akad Akad_Code

Akad_Desc

Menyimpan informasi

mengenai tipe-tipe akad

pembiayaan di Bank X

Akad Code

3. Segment Akad_Code

Product_Group

Segment_Level_1_Code

Segment_Level_1_Desc





Menyimpan informasi

mengenai segmentasi

pembiayaan untuk semua jenis

kredit.

Akad_Code

Segment_Level_1

_Code

Segment_Level_2

_Code

Segment_Level_3

_Code


96


No Dimensi Field Deskripsi Hierarki 4. Collective

Group

Impairment_Code

Impairment_Group

Menyimpan informasi

parameter konfigurasi group

dari kredit yang mempunyai

karakteristik kredit yang

homogen untuk proses

perhitungan PD dan LGD.

Didasarkan atas segment dari

pembiayaan.

Impairment_Grou

p

5. Currency Currency Group

Currency Code

Currency Desc

Menyimpan informasi

mengenai jenis-jenis mata uang

yang ada dengan hirarki valas,

non valas, currency code dan

deskripsi dari mata uang

Currency Group

Currency Code

6. Branch Branch_Code

Branch_Name

Main_Branch_Code

Main_Branch_Name

Area_Code

Area_Name

Menyimpan informasi cabang

dari Bank X termasuk regional

area terkait

Branch

Main Branch

Area

7. Kolektibilitas Collectibility Code

Collectibility Desc

Menyimpan informasi

kolektibilitas Bank Indonesia

sebagai profil risiko setiap

debitur (1, 2,3,4, 5)

Collectibility

Code

8. Produk Akad Code

Akad Desc

Product Code

Product Description

Menyimpan informasi

mengenai produk pembiayaan

yang ada di Bank X untuk

seluruh akad pembiayaan

Akad Code

Product Code

9. Movement

Collect

Movement_Coll_Code

Movement_Coll_Desc

Menyimpan informasi

pergerakan atau perubahan

kolektibilitas

Movement

Collect Code

10. Maturity

Profile Bucket

MaturityProfile_ID

MaturityProfile_Desc

Menyimpan informasi

mengenai range/sebaran

kelompok jatuh tempo

pembiyaaan

MaturityProfile_C

ode

11. Impairment

Flag

Impairment_Flag

Impairment_Desc

Menyimpan informasi

klasifikasi impairment yaitu

Collective dan Individual

Impairment Flag


97


No Dimensi Field Deskripsi Hierarki 12. Customer Customer Meyimpan informasi mengenai

Customer

Customer

b. Daftar Tabel-Tabel Dimensi dan Struktur Datanya

Tabel 4.10 sampai dengan Tabel 4.23 menjelaskan rincian sturktur data dari

masing-masing ke-14 dimensi.

1. Dimensi Period : DIM_PERIOD

Tabel 4.10 Deskripsi Tabel DIM_PERIOD

Nama Field Tipe

Data

Ukuran Keterangan

Period_SK int Primary Key dari Dimensi Period

DIM_YEAR Int Periode Tahun

DIM_SEMESTER Varchar 10 Periode Semester, Format S1 - [TAHUN] dan S2 -

[tahun]

DIM_QUARTER Varchar 20 Periode Quarter, Format : Q1, Q2, Q3, Q4

DIM_MONTH Varchar 10 Periode Bulan, Format : [Tahun]-Jan, [Tahun]-Feb,

dst

DIM_DATE Date Periode Tanggal, Format : yyyy-mm-dd

ISEOQ Varchar 1 Keterangan Akhir Quarter, Diisi Y jika akhir Kuartal

dan N jika bukan akhir kuartal

ISEOY varchar 1 Keterangan Akhir Tahun, Diisi Y jika akhir Tahun

dan N jika bukan akhir tahun

CreatedDate Date Tanggal dimana Dimensi Period ini dicreate dan

diupdate

2. Dimensi Akad : DIM_AKAD

Tabel 4.11 Deskripsi Tabel DIM_AKAD Nama Field Tipe

Data

Ukuran Keterangan

Akad_Code varchar 1 Primary Key; Kode Pembiayaan berdasarkan

tipe dari akad. Kodenya adalah A, B, C, D, E

Akad_Description varchar 50 Nama Akad. Contoh : Murabahah, Mudharabah,

Musyarakah, Qardh, Ijaroh


98


Nama Field Tipe

Data

Ukuran Keterangan

UpdatedDate date Tanggal dimana Dimensi Currency ini diupdate

CreatedDate date Tanggal dimana Dimensi Currency ini dicreate

dan diupdate

3. Dimensi Segment :

DIM_SEGMENT

Tabel 4. 12 Deskripsi Tabel DIM_SEGMENT Nama Field Tipe

Data

Ukuran Keterangan

Segment_SK Int 4 Primary Key dari Dimensi Segment

Akad_Code varchar 1 Foreign Key ; Akad Code

Segment_Level_1_Code int Kode dari Segmentasi Level 1

Segment_Level_1_Desc Varchar 50 Consumer, Non-Consumer


Segment_Level_2_Desc Varchar 50 Corporate, Retail-SME, Consumer


Segment_Level_3_Desc varchar 50 11,12,13,14,15, 21, 31, 41, 42, 43, 44, 45, 46,

47, 48

UpdatedDate date Tanggal dimana Dimensi Currency ini

diupdate

CreatedDate date Tanggal dimana Dimensi Currency ini

dicreate dan diupdate

4. Dimensi Collective Group

Nama Tabel DIM_IMPAIRMENT_GROUP

Tabel 4. 13 Deskripsi Tabel DIM_IMPAIRMENT_GROUP

Nama Field Tipe

Data

Uku

ran

Keterangan

ImpairmentGroup

_SK

int 4 Primary Key dari Dimensi Impairment Group yang didapat

dari Parameter Segment dengan Impairment Group

Impairment_Grou

p

varchar 50 Description dari Impairment Group


CreatedDate date Tanggal dimana Dimensi Currency ini dicreate dan diupdate


99


5. Dimensi Currency :

Nama Tabel DIM_CURRENCY

Tabel 4 14 Deskripsi Tabel DIM_CURRENCY Nama Field Tipe Data Ukuran Keterangan

Currency_Group Varchar 3 Diisi dengan Valas/Foreign Currency =FCY dan non

valas = IDR

Currency_Code Varchar 3 Primary Key; Mata uang dari masing-masing kurs.

Currency_Desc varchar 200 Deskripsi dari mata uang


CreatedDate date Tanggal dimana Dimensi Currency ini dicreate dan

diupdate

6. Dimensi Area

Tabel 4.15 Deskripsi Tabel DIM_AREABRANCH Nama Field Tipe Data Ukuran Keterangan

AreaBranch_SK Int 4 Surrogate Key dari Dimensi AreaBranch

Area_Code Int 4 Kode Area

Area_Desc Varchar 200 Nama Area

UpdatedDate date Tanggal dimana Dimensi Area Branch ini diupdate

CreatedDate date Tanggal dimana Dimensi Area Branch ini dibuat

7. Dimensi Main Branch

Tabel 4.16 Deskripsi Tabel DIM_MAINBRANCH Nama Field Tipe Data Ukuran Keterangan

MainBranch_SK Int Surrogate Key dari Dimensi MainBranch

AreaBranch_SK Int Foreign Key dari Tabel DIM_AREABRANCH

Main_Branch_Code Int 5 Kode Cabang Utama

Main_Branch_Name Varchar 200 Nama Cabang Utama

UpdatedDate Date Tanggal dimana Dimensi Main Branchini diupdate

CreatedDate Date Tanggal dimana Dimensi Main Branch ini dibuat


100


8. Dimensi Branch

Tabel 4.17 Deskripsi Tabel DIM_BRANCH

Nama Field Tipe Data Ukuran Keterangan

Branch_SK Int Surrogate Key dari Dimensi Branch

MainBranch_SK int Foreign Key dari Tabel DIM_MAINBRANCH

Branch_Code varchar 5 Kode Cabang

Branch_Name Varchar 200 Nama Cabang

UpdatedDate date Tanggal dimana Dimensi Branch ini diupdate

CreatedDate date Tanggal dimana Dimensi Product ini dicreate

9. Dimensi Kolektibilitas

Tabel 4. 18 Deskripsi Tabel DIM_COLLECTIBILITY


Collectibility_Code Int 4 Primary Key; Kode Kolektibilitas

Collectibility_Desc varchar 5 Deskripsi dari Kolektibilitas

CreatedDate Date Tanggal dimana Dimensi Collectibility ini

degenerate dan diupdate

10. Dimensi Produk

Tabel 4.19 Deskripsi Tabel DIM_PRODUCT


Product_SK Int 4 Surrogate Key dari Dimensi Product

Akad_Code Int 4 Kode Dari Akad – Link dari Dimensi Akad

(Akad_Code)

Product_Code varchar 5 Kode Dari Product Pembiayaan untuk masing-

masing akad

Product_Desc varchar 200 Deskripsi dari Product

CreatedDate Date Tanggal dimana Dimensi Product ini degenerate dan

diupdate


101


11. Dimensi Movement Kolektibilitas

Tabel 4.20 Deskripsi Tabel DIM_COLLECTABILITY_MOVEMENT


CollectMovement_SK Int 4 Primary Key dari Dimensi Movement

Collectability

CollectMovement_Desc varchar 5 Akan diisi dengan deskripsi berikut : 1-0, 1-1, 1-

2, 1-3, 1-4, 1-5, 2-1, 2-2, 2-3, 2-4, 2-5, 3-1, 3-2,

3-3, 3-4, 3-5, 4-1, 4-2, 4-3, 4-4, 4-5

5-1, 5-2, 5-3, 5-4, 5-5, 1-0, 2-0, 3-0, 4-0, 5-0.

CollectMovement_Flag varchar 200 0 : Account pembiayaan sudah non-aktif yang

mungkin disebabkan karena matured sesuai

tanggal jatuh tempo, atau mengalami pelunasan

dipercepat atau sudah di writeoff (WO)

1 : Tidak Mengalami Perubahan Kolektibilitas

dari bulan pelaporan ke bulan lalu

2: Mengalami perubahan kolektibilitas yang

membaik dari bulan pelaporan ke bulan lalu

3: Mengalami perubahan kolektibilitas yang

memburuk dari bulan pelaporan ke bulan lalu

CreatedDate Date Tanggal dimana Dimensi Movement

Collectabilityini diupdate

12. Dimensi Maturity Profile

Tabel 4. 21 Deskripsi Tabel DIM_MATURITY_PROFILE


MaturityProfile_SK Int 4 Surrogate Key dari Dimensi Maturity Profile

MaturityDayFrom Int 4 Diisi dengan jumlah range hari

MaturityDayTo Int 4 Diisi dengan jumlah range hari

MaturityProfile_Desc Varchar 50 Up to 1 month, >1 to 3 months, >3 to 6 months, >6

months to 1 year, >1 to 3 years, >3 to 5 years, Over 5

years.

CreatedDate Date Tanggal dimana Dimensi Maturity Profile ini

degenerate dan diupdate


102


13. Dimensi Impairment Flag

Tabel 4.22 Deskripsi Tabel DIM_IMPAIRMENT_FLAG Nama Field Tipe Data Ukuran Keterangan

ImpairmentFlag_Code varchar 2 Primary Key

Kode yang digunakan adalah C dan I

ImpairmentFlag_Desc Varchar 100 C= Collective Assesment, I= Individual Assesment

CreatedDate Date Tanggal dimana Dimensi Impairment Flag ini

degenerate atau diupdate

14. Dimensi Customer

Tabel 4.23 Deskripsi Tabel DIM_CUSTOMER


Customer_SK int 4 Surrogate Key dari Dimensi Impairment Flag

Customer_Number varchar 50 Kode Customer

Global_Customer_Number varchar 50 Kode Global Customer Number

Customer_Name Varchar 300 Nama Dari Customer

Customer_Grade varchar 5 Internal Rating dari Customer

Customer_Type varchar 5 Type dari customer (resident, non resident)

CreatedDate date Tanggal dimana Dimensi Impairment Flag ini

diupdate

c. Perancangan Skema

Dalam perancangan datamart ini, skema yang digunakan adalah skema bintang

untuk masing-masing Tabel Fakta dan Tabel Dimensi yang terkait. Dimana

terdapat tabel dimensi yang digunakan antara beberapa tabel Fakta yang berbeda

sehingga menyebabkan relational many to one antara foreign key pada kedua

tabel fakta tersebut. Dimensi tersebut antara lain adalah Dimensi Period, Dimensi

Product, Dimensi Segment, Dimensi Kolektibilitas, Dimensi Currency atau

disebut sebagai Conformed Dimension. Pemecahan skema tersebut berdasarkan

tabel fakta nya, digambarkan dalam skema-skema berikut dibawah ini :


103


MEA

SURE

MEN

T

Gambar 4.3 Skema Pembiayaan (Loan)

Gambar 4.3 menggambarkan mengenai skema pembiayaan yang menunjukkan

jumlah transaksi pembiayaan dengan berbagai pengukurannya. Skema

pembiayaan ini yang dibentuk dari 10 tabel dimensi dan 1 tabel fakta Tabel Fakta

terdiri dari field-field yang berkaitan dengan dimensi (download_date, akad_code,

segment_sk, currency_code, main_branch_code, branch_code, bi_collectability,

product_code, collectmovement_sk, maturityprofile_sk) dan field-field yang

berkaitan dengan measurement (outstanding, numberofaccount, plafond,

nonperfomingloan, npl_ratio).

Relational skema bintang ini melibatkan masing-masing 1 primary key pada tabel

dimensi dan 1 foreign key pada tabel fakta yang terkait dengan dimensi

tersebut.Tujuannya adalah untuk mendapatkan response time yang cepat dalam

proses mengakses data pembiayaan.


104


Gambar 4.4 Skema Cadangan Kerugian Penurunan Nilai (CKPN)

Gambar 4.4 menggambarkan mengenai skema Cadangan Kerugian Penurunan

Nilai (CKPN) yang menunjukkan jumlah transaksi perhitungan CKPN dengan

berbagai pengukurannya.Skema CKPN ini yang dibentuk dari 11 tabel dimensi

dan 1 tabel fakta. Tabel Fakta CKPN terdiri dari field-field yang berkaitan dengan

dimensi (download_date, akad_code, segment_sk, impairmentgroup_code,

currency_code, main_branch_code, branch_code, bi_collectability, product_code,

collectmovement_sk, customer_number dan ia_ca_flag) dan field-field yang

berkaitan dengan measurement (PD_rate, LGD_rate, Expected_Loss_Rate,

outstanding, outstanding_idr, plafond, plafond_idr, collateral_value,

collateral_value_idr, ckpnkolektif, ckpnkolektif_idr, ckpnindividual,

ckpnindividual_idr, unwinding_amount, unwinding_idr, charge, charge_idr,


105


writeback, writeback_idr, ckpnforecast, ckpnforecast_idr, ppap,

impaired_loan_ratio).

Relational skema bintang ini melibatkan masing-masing melibatkan 1 primary key

pada tabel dimensi dan 1 foreign key pada tabel fakta yang terkait dengan dimensi

tersebut dengan relasi jenis many to one. Tujuannya adalah untuk mendapatkan

response time yang cepat dalam proses mengakses data CKPN

4.3.7 Pemilihan Durasi dan Basis data (Choosing the duration of the database)

Data yang diambil berasal dari core banking system, cakupan periode data yang

di-load minimal selama 3 tahun data. Pada penelitian ini data digunakan mulai

dari bulan Mei 2010 sampai dengan bulan Februari 2014 dengan posisi data setiap

bulannya pada akhir bulan pelaporan. Menentukan batas waktu dari umurdata

yang diambil dan akan dipindahkan ke dalam tabel fakta. Misalnya, data

perusahaan dua tahun lalu atau lebih diambil dan dimasukkan dalam tabel fakta.

Tabel 4.24 menjelaskan durasi dan basis data dalam perancangan datamart PSAK

50/55

Tabel 4.24 Durasi dan Basis Data dalam perancangan Datamart PSAK 50/55

Nama

Database

OLAP

Nama

Database

OLTP

Periode

Waktu OLTP

Transformasi

Data ke datamart

Durasi

Data mart

OLAP_BMI OLTP-Bank 2014 2010-2014 5 tahun

4.3.8 Melacak Perubahan Dimension Secara Perlahan (Tracking Slowly

Changing Dimensions)

Adapun melacak perubahan dimensi dapat dilakukan dengan empat jenis

perubahan, antara lain : Pertama adalah atribut dimensi yang tidak pernah

berubah, dimana fact selalu dikelompokkan ke dalam original value atau disebut

Slowly Changing Dimension (SCD) Type 0, jenis kedua adalah mengganti secara

langsung pada tabel dimensiatau disebut SCD Type 1,perubahan berikutnya

adalah dengan cara pembentukan record baru untuk setiap perubahan baru,


106


dimana ditandai dengan adanya surrogate key. Perubahan jenis ini dapat disebut

dengan SCD Type 2, dan terakhir adalah perubahan data dengan membuat kolom

baru atau disebut dengan SCD Type 3.

Menentukan Perubahan dimensi ini merupakan langkah yang penting yang harus

dilakukan dalam rangka proses loading menggunakan dimensional data model.

Proses loading dimension tabel merupakan proses yang harus dilalui sebelum

melakukan loading ke Tabel Fakta. Oleh karena itu dari ke-14 dimensi yang telah

disebutkan dibagian sub bab 4.3.6 melengkapi Tabel 4.10, dapat disampaikan

pada tabel 4.25 mengenai kondisi perubahan untuk setiap dimensi yang ada.:

Tabel 4.25 Tabel Pelacakan Perubahan Dimensi No. Nama Dimensi / Nama

Tabel Dimensi

Type

Perubahan

Dimensi

Keterangan

1 Period / DIM_PERIOD SCD Type 0 Tanggal merupakan attribute yang fixed yang tidak

pernah berubah (durable) dan terdapat hirarki untuk

kepentingan drill down dan drill up yaitu day, month,

quarter, year.

2 Akad / DIM_AKAD SCD Type 0 Tipe Akad pembiayaan merupakan atribut yang fixed

dan descriptionnya tidak akan berubah.

3 Segment /

DIM_SEGMENT

SCD Type 2 Tipe Segmentasi level 3

(SEGMENT_LEVEL_3_CODE,

SEGMENT_LEVEL_3_DESC) akan berubah seiring

dengan perubahan kebijakan pengelompokkan

kredit.Akan dilakukan update pada start date dan end

date, dan flag Current terhadap record yang mengalami

perubahan nama segment dan kelompok segment yang

ada ketika adanya perubahan sehingga segment yang

lama masih tetap di maintain pada histori tabel

4 Collective Group /

DIM_IMPAIRMENT_GR

OUP

SCD Type 2 Tipe pengelompokkan Collective Group

(IMPAIRMENT_CODE) per masing-masing segment

akan berubah seiring dengan perubahan kebijakan

pengelompokkan kredit terkait dengan Dimensi

Segment. Setiap kali ada perubahan segmentasi,

Collective Group akan dimapping kembali. Untuk itu

akan dilakukan flag Current terhadap perubahan

Segment yang ada untuk setiap adanya perubahan dan

segment yang lama masih tetap di maintain pada

history.


107


No. Nama Dimensi / Nama

Tabel Dimensi

Type

Perubahan

Dimensi

Keterangan

5 Currency /

DIM_CURRENCY

SCD Type 0 Jenis Currency atau mata uang merupakan atribut yang

fixed

6 Area / DIM_AREA SCD Type 2 Area (AREA_CODE) dapat berubah menjadi cakupan

yang baru akibat perluaasan cabang dan reorganisasi.

7 Cabang Utama /

DIM_MAINBRANCH

SCD Type 2 Main Branch (MAIN_BRANCH_CODE) dapat

berubah menjadi cakupan Area yang baru, karena

perubahan kebijakan atau karena adanya pembukaan

cabang yang baru.

8 Cabang / DIM_BRANCH SCD Type 2 Kode cabang (BRANCH_CODE) dapat berubah

menjadi cakupan main branch karena perluasan

wilayah atau karena reorganisasi cabang. Untuk itu

histori tetap mengacu kepada wilayah sebelumnya. Hal

ini akan ditambahkan kolom Status untuk mengetahui

status itu current dan kolom date start dan date end

untuk mendeteksi perubahan kode cabang.

9 Kolektibilitas /

DIM_COLLECTABILITY

SCD Type 0 Nilai dari kolektibilitas (COLLECTIBILITY_CODE)

akan selalu fixed dari 1 sampai dengan 5 sesuai dengan

kebijakan dari Bank Indonesia

10 Produk / DIM_PRODUCT

SCD Type 2 Berdasarkan kode produk (PRODUCT_CODE) dan

kode akad (AKAD_CODE) variable yang mungkin

berubah adalah Product Description

(PRODUCT_DESC). Terdapat field date start dan date

end untuk setiap perubahan terhadap product

description dari masing-masing product_code tersebut

untuk mengetahui periode perubahan product

description tersebut dan dilakukan insert new record

dengan surrogate key sehingga pada saat join ke fact

tabel hanya menggunakan satu key saja sebagai

identifier.

11 Movement Collect /

DIM_COLLECTABILITY

_MOVEMENT

SCD Type 0 Tidak akan ada perubahan data untuk movement

kolektibilitas ini. Value untuk movement collectability

ini adalah fixed dan tidak akan berubah yaitu value 1-1,

1-2, dst.

12 Maturity Profile Bucket /

DIM_MATURITYPROFI

LE

SCD Type 2 Apabila ada perubahan di ID_MaturityProfile baik

perubahan description pada ID yang sama, atau

penambahan new ID dengan Description yang baru,

makaselalu akan ditambahkan record yang baru untuk

setiap kali adanya perubahan untuk semua description

yang baru.


108


No. Nama Dimensi / Nama

Tabel Dimensi

Type

Perubahan

Dimensi

Keterangan

13 Impairment Flag /

DIM_IMPAIRMENT_FL

AG

SCD Type 0 Flag Impairment adalah fixed yaitu I dan C dan tidak

pernah berubah

14 Customer /

DIM_CUSTOMER

SCD Type 1 Apabila terdapat perubahan (contoh Nama Customer),

maka perubahan tersebut akan langsung diupdate ke

record yang sama berdasarkan primary key di tabel

DIM_CUSTOMER.

4.3.9 Memutuskan Prioritas dan Mode dari Query (Deciding the Query

Priorities and the Query Modes)

Pada tahap ke-9 ini menggunakan perancangan fisik (physical design) untuk data

mart . Perancangan fisik ini berkaitan dengan proses analisa kapasitas media

penyimpanan. Berikut ini merupakan proses yang dilakukan pada tahap ini,

Dalam membangun sebuah data martdi Bank X maka diperlukannya analisa

kapasitas media penyimpanan. Analisis kapasitas media penyimpanan ini

dilakukan agar dapat mempersiapkan jumlah kapasitas media penyimpanan

sehingga dapat menampung data yang akan terus bertambah daritahun ke tahun.

Berikut ini merupakan analisa kapasitas media penyimpanan dalam tabel staging,

tabel fakta dan tabel dimensi:

1. Analisa Kapasitas Media Penyimpanan Data Staging

Tabel 4.27 dapat dilihat bahwa total records selama 3 tahun terakhir posisi akhir

bulan pelaporan mulai dari tahun May-2010 s/d Jan-2014 adalah 2.908.000

records, yang terdiri dari May2010-Dec2010 sebanyak 215,688 records, Jan

2011-Dec2011 sebanyak 440.448 records, Jan 2012-Dec 2012 sebanyak 764.699

recods, Jan 2013-Dec 2013 sebanyak 1.358.061. Rata-rata jumlah records per

tahun adalah 855.000 s/d 1.200.000 dengan rata-rata jumlah records per bulan

sebanyak 110.000 – 150.000. Growth selama Jan-2011 s/d Dec-2013 rata-ratanya

adalah sebanyak 185% (May 2010 ke May 2011 +/- 204%, Jan 2011 ke Dec 2012

= 174%, Jan 2012 ke Dec 2013 = 178%). Maka estimasi jumlah kebutuhan size

dapat dijabarkan sebagai berikut :


109


- Number of Rows = 150.000 x 12 = 1.800.000 rows

- Number of Columns = 137 columns

- Fixed Data Size =638 byte

- Variable Data Size = 1470 byte, with maximum varchar size = 255 byte

- Null Bitmap = 2 + (Number of Columns) +7) / 8 + Max Varchar size = 2 +

(137 +7)/8 + 255 = 275

- Row Size = Fixed Data Size + Variable Data Size + Null Bitmap + 4

- Row Size = 638 + 1470 + 275 + 4 = 2387

- Row Per Page = 8096 / (Row_size + 2 ) = 8096 / (2387+2) = 3.388865634

- Num Pages = Num_Rows/Rows Per Page = 1.800.000 / 3.388865634 =

531,151.1858

- Heap Size = 8192 x 531,151.1858 = 4,351,190,514 bytes = 4.05 Giga

Bytes

Jadi kapasitas media penyimpanan data yang diperlukan dalam 5 tahun adalah

4,351,190,514 bytes x 5 tahun = 21,755,952,569 bytes atau 20.26 Giga Bytes.

Tabel 4.26 berisi mengenai estimasi data staging pada tabel

PSAK_MASTER_ACCOUNT periode Mei 2010 sampai dengan Desember 2013.

Tabel 4. 26 Tabel Estimasi Data Staging pada PSAK_MASTER_ACCOUNT untuk periode Mei 2010- Desember 2013

Periode Data Total Record

Growth

compared with

previous Month

%Growth

Monthly

6/30/2010 25923 -116 -0.44549

7/31/2010 26088 165 0.6365

8/31/2010 26626 538 2.062251

9/30/2010 26837 211 0.792458

10/31/2010 27617 780 2.906435

11/30/2010 28040 423 1.531665

12/31/2010 28518 478 1.704708

1/31/2011 29528 1010 3.541623

2/28/2011 30518 990 3.35275

3/31/2011 32278 1760 5.767088

4/30/2011 33804 1526 4.727678

5/31/2011 35466 1662 4.916578


110


Periode Data Total Record

Growth

compared with

previous Month

%Growth

Monthly

6/30/2011 37153 1687 4.756668

7/31/2011 38280 1127 3.033402

8/31/2011 39812 1532 4.00209

9/30/2011 40378 566 1.421682

10/31/2011 40478 100 0.24766

11/30/2011 40868 390 0.963486

12/31/2011 41885 1017 2.4885

1/31/2012 42397 512 1.222395

2/29/2012 43628 1231 2.903507

3/31/2012 44980 1352 3.098927

4/30/2012 47124 2144 4.766563

5/31/2012 49797 2673 5.672269

6/30/2012 56711 6914 13.88437

7/31/2012 63893 7182 12.66421

8/31/2012 70089 6196 9.697463

9/30/2012 75251 5162 7.364922

10/31/2012 80452 5201 6.911536

11/30/2012 90968 10516 13.07115

12/31/2012 99409 8441 9.279087

1/31/2013 103044 3635 3.656611

2/28/2013 107575 4531 4.397151

3/31/2013 110850 3275 3.044388

4/30/2013 114250 3400 3.067208

5/31/2013 115744 1494 1.307659

6/30/2013 118324 2580 2.229057

7/31/2013 115416 -2908 -2.45766

8/31/2013 114613 -803 -0.69574

9/30/2013 115235 622 0.542696

10/31/2013 112853 -2382 -2.06708

11/30/2013 112500 -353 -0.3128

12/31/2013 117657 5157 4.584

1/31/2014 128654 10997 9.34666


111


2. Analisis Kapasitas Media Penyimpanan Tabel Fakta Pembiayaan

Berdasarkan hasil proses load ke Fact_Loan pada posisi tanggal 31 January 2014.

Fact_Loan terdiri dari 16 kolom yang teridi dari 9 field berupa fixed tipe dan 7

field berupa variabel data size.

Data yang akan masuk ke tabel ini diperkirakan +/- 1300 – 1500 rows atau 11-

12% populasi dari tabel sumber yaitu tabel PSAK_MASTER_ACCOUNT, karena

tabel ini sudah di summary dan sudah di dilakukan data cleansing, filtering

berdasarkan tanggal pelaporan (download_date), akad_code, segment, currency,

area_code, main_branch_code, branch_code, bi_collectability, product_code,

collectmovement_sk, maturityprofile_code.

- Number of Rows = 1518 x 12 = 18.216 rows

- Number of Columns = 16 columns

- Fixed Data Size = 22 byte

- Variable Data Size = 122 byte, with maximum varchar size = 20 byte

- Null Bitmap = 2 + (Number of Columns) +7) / 8 + Max Varchar size = 2 +

(137 +7)/8 + 255 = 275

- Row Size = Fixed Data Size + Variable Data Size + Null Bitmap + 4

- Row Size = 638 + 1470 + 275 + 4 = 2387

- Row Per Page = 8096 / (Row_size + 2 ) = 8096 / (2387+2) = 3.388865634

- Num Pages = Num_Rows/Rows Per Page = 18.216 / 3.388865634 =

5375.25 Heap Size = 8192 x 5375.25 = 44.034.048 bytes = 0.041 Giga

Bytes

Jadi kapasitas media penyimpanan data yang diperlukan dalam 5 tahun adalah

0.041 Giga bytes x 5 tahun = 0.20 Giga Bytes

4.4 Proses ETL

Sesuai dengan rancangan arsitektur Datamart PSAK maka proses ETL dibedakan

menjadi 3 proses yang terdiri dari proses ekstraksi dan transformasi data staging,

proses transformasi dan load tabel Dimensi dan proses transformasi dan load tabel

Fakta.


112


4.4.1 Proses Ekstrak dan Transformasi Data Staging

4.4.1.1 Ekstraksi Data Pembiayaan

Pada bagian ini menjelaskan ekstraksi dari semua sumber data pembiayaan dari

sumber tabel Core bankingsystems (ILN, JF, MCB, CRD) berdasarkan rules

transformasi per masing-masing sumber data yang disebutkan pada bagian

4.1.3.Nama Text Files hasil penggabungan dari berbagai sumber data tersebut

PSAK_MASTER_ACCOUNT_EDW. Masing-masing struktur format data dalam

bentuk textfile dengan pipe delimited format. Dari ekstraksi text file

PSAK_MASTER_ACCOUNT_EDW tersebut, maka dilakukan load

menggunakan bulk insert. Seluruh data type per masing-masing delimited format

dalam format text (string) ke tabel PSAK_MASTER_ACCOUNT_EDW, proses

selanjutnya transformasi ke masing-masing data type untuk setiap field di satu

tabel final yaitu PSAK_MASTER_ACCOUNT.

Proses Ekstraksi ini dilakukan setiap bulan sekali setelah proses End Of Month

closing data dari masing-masing core banking sistem telah selesai diproses

menjadi input text files. Proses ekstraksi data pembiayaan ini dilakukan satu bulan

sekali pada setiap tanggal 1 awal bulan untuk data posisi data akhir bulan.

Gambar 4.5 Ekstraksi dan Transformasi Data Pembiayaan ke masing-masing tabel


113


Tabel 4.27 menjelaskan struktur data pada tabel staging

PSAK_MASTER_ACCOUNT yang akan menampung semua data pembiayaan di

Bank X.

Tabel 4.27 Struktur Data PSAK_MASTER_ACCOUNT

NO FIELD DATA TYPE LENGTH 1 MASTER_ACCOUNT_ID VARCHAR2 (50 Byte) 2 DOWNLOAD_DATE DATE 3 INSTRUMENT_CLASSIFICATION VARCHAR2 (10 Byte) 4 DATA_SOURCE VARCHAR2 (20 Byte) 5 PRODUCT_TYPE VARCHAR2 (20 Byte) 6 PRODUCT_CODE VARCHAR2 (20 Byte) 7 BRANCH_CODE VARCHAR2 (20 Byte) 8 ACCOUNT_NUMBER VARCHAR2 (50 Byte) 9 ACCOUNT_NUMBER_PREVIOUS VARCHAR2 (50 Byte)

10 FACILITY_NUMBER VARCHAR2 (50 Byte) 11 NO_REK_ANGSURAN VARCHAR2 (50 Byte) 12 CUSTOMER_NUMBER VARCHAR2 (50 Byte) 13 CUSTOMER_NAME VARCHAR2 (100 Byte) 14 GLOBAL_CUSTOMER_NUMBER VARCHAR2 (20 Byte) 15 ACCOUNT_STATUS VARCHAR2 (5 Byte) 16 LOAN_START_DATE DATE 17 LOAN_DUE_DATE DATE 18 LOAN_START_AMORTIZATION DATE 19 LOAN_END_AMORTIZATION DATE 20 NEXT_PAYMENT_DATE DATE 21 LAST_PAYMENT_DATE DATE 22 FIRST_INSTALLMENT_DATE DATE 23 ACCRUAL_DATE DATE 24 TENOR INTEGER 25 PSAK_ACCT_STATUS VARCHAR2 (3 Byte) 26 PMT_SCH_STATUS CHAR (1 Byte) 27 EIR_STATUS CHAR (1 Byte) 28 ECF_STATUS CHAR (1 Byte) 29 PAYMENT_CODE VARCHAR2 (20 Byte) 30 PAYMENT_TERM VARCHAR2 (2 Byte) 31 INTEREST_CALCULATION_CODE VARCHAR2 (20 Byte) 32 INSTR_CLASS VARCHAR2 (10 Byte) 33 IAS_CLASS VARCHAR2 (10 Byte) 34 SOURCE_PROCESS VARCHAR2 (100 Byte) 35 RESIDENCE_TYPE VARCHAR2 (15 Byte) 36 CURRENCY CHAR (3 Byte)


114


NO FIELD DATA TYPE LENGTH 37 EXCHANGE_RATE NUMBER (19,6) 38 OUTSTANDING NUMBER (32,6) 39 OUTSTANDING_PREVIOUS NUMBER (32,6) 40 PLAFOND NUMBER (32,6) 41 UNUSED NUMBER (32,6) 42 COMMITTED_FLAG CHAR (1 Byte) 43 INTEREST_RATE NUMBER (32,6) 44 AMORT_TYPE VARCHAR2 (10 Byte) 45 EIR FLOAT 46 EIR_AMOUNT NUMBER (32,6) 47 FAIR_VALUE_AMOUNT NUMBER (32,6) 48 INITIAL_UNAMORT_TXN_COST NUMBER (32,6) 49 INITIAL_UNAMORT_ORG_FEE NUMBER (32,6) 50 UNAMOR_TRANS_COST_AMT NUMBER (32,6) 51 UNAMOR_ORIGINATION_FEE_AMT NUMBER (32,6) 52 DAILY_AMORT_AMT NUMBER (32,6) 53 DAY_PAST_DUE INTEGER 54 DAY_PAST_DUE_START_DATE DATE 55 ORIGINAL_COLLECTABILITY VARCHAR2 (10 Byte) 56 BI_COLLECTABILITY INTEGER 57 SEGMENT VARCHAR2 (255 Byte) 58 PRODUCT_GROUP VARCHAR2 (100 Byte) 59 DPD_ID INTEGER 60 PD_RATE FLOAT 61 LGD_RATE FLOAT 62 PIP_AMOUNT FLOAT 63 IIP_AMOUNT FLOAT 64 UNWINDING_AMOUNT FLOAT 65 BEGINNING_BALANCE FLOAT 66 CHARGE FLOAT 67 WRITEBACK FLOAT 68 ENDING_BALANCE FLOAT 69 IS_IMPAIRED VARCHAR2 (1 Byte) 70 IMPAIRED_FLAG CHAR (1 Byte) 71 WRITE_OFF_FLAG CHAR (1 Byte) 72 STAFF_LOAN_FLAG VARCHAR2 (1 Byte) 73 RESTRUCTURED_LOAN_FLAG CHAR (1 Byte) 74 RESTRUCTURE_DATE DATE 75 INTEREST_IN_SUSPEND NUMBER (32,6) 76 SAM_FLAG CHAR (1 Byte) 77 NON_SAM_FLAG CHAR (1 Byte) 78 SAM_IMPAIRED_DATE DATE


115


NO FIELD DATA TYPE LENGTH 79 NON_SAM_IMPAIRED_DATE DATE 80 IMPAIRED_INTEREST_RATE NUMBER (19,6) 81 DPD_FLAG CHAR (1 Byte) 82 TOTAL_GENERAL_PROVISION NUMBER (32,6) 83 TOTAL_SPECIFIC_PROVISION NUMBER (32,6) 84 CUSTOMER_GRADE CHAR (3 Byte) 85 INTEREST_WITHHELD NUMBER (32,6) 86 ACOD VARCHAR2 (18 Byte) 87 AO_CODE VARCHAR2 (100 Byte) 88 AO_NAME VARCHAR2 (50 Byte) 89 VALCTR_CODE VARCHAR2 (10 Byte) 90 REVOLVING_FLAG CHAR (1 Byte) 91 EIR_CHANGES_FLAG CHAR (1 Byte) 92 LAST_EIR_CHANGE_DATE DATE 93 EIR_CHANGES_SEQUENCE CHAR (50 Byte) 94 INSTALLMENT_GRACE_PERIOD DATE 95 INSTALLMENT_AMOUNT NUMBER (32,6) 96 CUSTOMER_TYPE CHAR (3 Byte) 97 ACCUMULATIVE_ACCRUED_INTEREST NUMBER (32,6) 98 DAILY_ACCRUED_INTEREST NUMBER (32,6) 99 DEATH_CASE_FLAG CHAR (1 Byte) 100 CITY VARCHAR2 (20 Byte) 101 MTD_PRINCIPAL_PAYMENT NUMBER (32,6) 102 MTD_INTEREST_PAYMENT NUMBER (32,6) 103 COLLATERAL_VALUE_FOR_IMPAIR NUMBER (32,6) 104 DPD_GROUP CHAR (10 Byte) 105 SPECIAL_FLAG CHAR (1 Byte) 106 PREV_RESTRUCTURED_LOAN_ACCOUNT VARCHAR2 (50 Byte) 107 COLL_CODE VARCHAR2 (5 Byte) 108 MTD_DAYS INTEGER 109 CFD_DAYS INTEGER 110 MTD_INTEREST_AMT NUMBER (32,6) 111 CFD_INTEREST_AMT NUMBER (32,6) 112 MTD_EIR_AMT NUMBER (32,6) 113 CFD_EIR_AMT NUMBER (32,6) 114 LOAN_AMT NUMBER (32,6) 115 GCN_CUST_GRADE CHAR (3 Byte) 116 OS_AFTER_IMPAIRMENT NUMBER (32,6) 117 IMPAIRMENT_CHARGE NUMBER (32,6) 118 RATIO_OUTS_TO_FACILITY NUMBER (12,6) 119 OUTSTANDING_ORG NUMBER (32,6) 120 UNAMOR_TRANS_COST_AMT_ORG NUMBER (32,6)


116


NO FIELD DATA TYPE LENGTH 121 UNAMOR_ORIGINATION_FEE_AMT_ORG NUMBER (32,6) 122 STEP_NO VARCHAR2 (50 Byte) 123 BRANCH_SUNGL VARCHAR2 (15 Byte) 124 DEPT_UNIT VARCHAR2 (15 Byte) 125 SANDI_BI VARCHAR2 (15 Byte) 126 UNEARNED_INCOME NUMBER (32,6) 127 BATCH_NUMBER VARCHAR2 (40 Byte) 128 CONTRA_AMOUNT NUMBER (17,2) 129 FINCO_ID CHAR (5 Byte) 130 PROVISION NUMBER (17,2) 131 DOWN_PAYMENT NUMBER (17,2) 132 OTR_PRICE NUMBER (17,2) 133 FLAG_DIF_ACCRUE_INTR_AMT CHAR (1 Byte) 134 DIFF_ACCRUE_INTEREST_AMOUNT NUMBER (17,2) 135 INPUT_USER_ID VARCHAR2 (10 Byte) 136 MERCHANT_RATE NUMBER (9,6) 137 UNAMOR_AMT_TOTAL NUMBER (32,6)

4.4.1.2 Ekstraksi Data CKPN

Untuk dapat membentuk data CKPN Final diperlukan proses persiapan data

CKPN yang dependent terhadap sumber data input manual yang di-maintain oleh

pengguna. File ekstraksi yang digunakan sebagai input dalam proses transformasi

CKPN ini adalah sebagai berikut :

- PSAK_IMPR_OVERRIDES : File yang berisi sebagai tempat penampung

data customer yang telah dioverride dari status kolektif ke individual dan

sebaliknya. File ini akan mengakumulasi semua daftar debitur yang akan

dilakukan flag impairment secara individual. Format file dalam bentuk Excel.

- PSAK_INDIVIDUAL_IMPAIRMENT: File yang berisi sebagai tempat

penampung data per level account pembiayaan untuk setiap customer untuk

setiap periode pelaporan. Satu customer memungkinkan memiliki banyak

account pembiayaan. Format file dalam bentuk Microsoft Excel.

- TBLT_PAYMENTEXPECTED : yaitu berisi data arus kas yang diupload

oleh user dan langsung di proses insert ke tabel ini. File Format dalam bentuk

Microsoft Excel.


117


- PSAK_EXPECTED_RECOV_UPLOAD :yaitu berisi data write off dan

recovery berdasarkan masing-masing segmentasi yang diupload langsung.

File Format dalam bentuk Microsoft Excel.

- PSAK_COLL_SHORTFALL_UPLOAD : yaitu berisi data collateral

berdasarakan masing-masing segmentasi yang diupload langsung ke suatu

folder. File Format dalam bentuk Microsoft Excel.

- PSAK_CKPN_TARGET : yaitu berisi data target pembentukan cadangan

kerugian penurunan nilai setiap bulannya dan diupload langsung ke suatu

folder. File Format dalam bentuk Microsoft Excel.

- PSAK_BMI_SEGMENT : yaitu berisi data mapping segmentasi ke group

impairment untuk perhitungan CKPN secara kolektif. Prosesnya adalah user

melakukan upload flat file ke folder tertentu setiap adanya perubahan group

impairment. File Format adalah dalam bentuk Microsoft Excel.

Prosesnya dari masing-masing ekstrak file tersebut akan di-load ke nama tabel

sesuai dengan nama ekstrak file tersebut dengan masing-masing struktur tabel

adalah sebagai berikut. Tabel 4.28 sampai dengan Tabel 4.35 menjelaskan proses

ektraksi masing-masing sumber data manual sebagai data input untuk pemrosesan

perhitungan CKPN.

1. Proses Ekstraksi File PSAK_IMPR_OVERRIDES ke Tabel

Tabel 4.28 Struktur Tabel PSAK_IMPR_OVERRIDES Nama Field Data Type

PKID INTEGER,

DOWNLOAD_DATE DATE,

CUSTOMER_NUMBER VARCHAR2(50 BYTE),

DATA_SOURCE VARCHAR2(50 BYTE),

BRANCH_CODE VARCHAR2(50 BYTE),

CUSTOMER_NAME VARCHAR2(2000 BYTE),

PLAFOND_IMPAIR NUMBER(32,6),

PLAFOND_CURRENT NUMBER(32,6),

DPD_IMPAIR FLOAT(126),

DPD_CURRENT FLOAT(126),

BI_COLLECT_IMPAIR FLOAT(126),

BI_COLLECT_CURRENT FLOAT(126),

FLAG_IMPAIRMENT VARCHAR2(1 BYTE),


118


Nama Field Data Type

METHOD VARCHAR2(50 BYTE),

REMARK VARCHAR2(2000 BYTE),

CREATED_BY VARCHAR2(50 BYTE),

CREATED_DATE DATE,

UPDATED_BY VARCHAR2(50 BYTE),

UPDATED_DATE DATE

2. Proses Ekstraksi File TBLT_PAYMENTEXPECTED ke Tabel

Tabel 4.29 Struktur Tabel TBLT_PAYMENTEXPECTED

Nama Field Data Type DOWNLOADDATE TIMESTAMP(3), CUSTOMERNUMBER VARCHAR2(50 BYTE), PKID NUMBER(19), CUSTOMERNAME VARCHAR2(100 BYTE) SEGMENT VARCHAR2(50 BYTE), PRDGROUP VARCHAR2(5 BYTE), PAYMENTPERIOD VARCHAR2(50 BYTE), PAYMENTDATE TIMESTAMP(3), CCY CHAR(3 BYTE), GROSSPROCEEDS NUMBER(19,4), MGTOVERRIDE NUMBER(19,4), REVISEDECF NUMBER(19,4), FSV NUMBER(19,4), NPVPERCENT NUMBER(19,4), DISCOUNTRATE NUMBER(19,4), NPV NUMBER(19,4), IPDISCOUNT NUMBER(19,4), IPP NUMBER(19,4), INTERESTUNWINDING NUMBER(19,4), STATUS VARCHAR2(3 BYTE), INPUTDATE TIMESTAMP(3), FACILITYNO VARCHAR2(50 BYTE), INTERESTRATE NUMBER(19,4), CREATEDBY VARCHAR2(50 BYTE), CREATEDDATE TIMESTAMP(3), UPDATEDBY VARCHAR2(50 BYTE), UPDATEDDATE TIMESTAMP(3), BEGINBALANCE NUMBER(19,4), EIR_AMOUNT NUMBER(19,4), ENDINGBALANCE NUMBER(19,4),


119


Nama Field Data Type

MASTER_ACCOUNT_ID VARCHAR2(50 BYTE), COLLVALUE NUMBER(19,4), COLLREFNO VARCHAR2(50 BYTE), ESTIMATECOST NUMBER(19,4), INTERESTESTIMATED NUMBER(19,4), PRINCIPAL NUMBER(19,4), INTERESTESTIMATEDPERCENT NUMBER(19,4), INTERESTEIR NUMBER(19,4)

3. Proses Ekstraksi File PSAK_EXPECTED_RECOV_UPLOAD ke Tabel

Tabel 4.30 Struktur Tabel PSAK_EXPECTED_RECOV_UPLOAD

Nama Field Data Type PERIODE VARCHAR2(6 BYTE), SEGMENT VARCHAR2(100 BYTE), WO NUMBER(32,6), RECOVERY NUMBER(32,6), AYDA NUMBER(32,6)

4. Proses Ekstraksi File PSAK_COLL_SHORTFALL_UPLOAD ke Tabel

Tabel 4.31 Struktur Tabel PSAK_COLL_SHORTFALL_UPLOAD

Nama Field Data Type PERIODE VARCHAR2(6 BYTE),

SEGMENT VARCHAR2(100 BYTE),

OUTSTANDING NUMBER(32,6), AGUNAN NUMBER(32,6)

5. Proses Ekstraksi File PSAK_CKPN_TARGET ke Tabel

Tabel 4.32 Struktur Tabel PSAK_CKPN_TARGET

Nama Field Data Type PERIODE DATE BRANCH_ID VARCHAR(20) CURRENCY CHAR(3) CKPNFORECAST NUMBER(32,6)

6. Proses Ekstraksi File PSAK_INDIVIDUAL_IMPAIRMENT ke Tabel


120


Tabel 4.33 Struktur Tabel PSAK_INDIVIDUAL_IMPAIRMENT

Nama Field Data Type DOWNLOAD_DATE DATE, EFFECTIVE_DATE DATE, CUSTOMER_NUMBER VARCHAR2(50 BYTE), MASTER_ACCOUNT_ID VARCHAR2(50 BYTE), INTEREST_RATE FLOAT(126), EIR FLOAT(126), IMP_STATUS CHAR(1 BYTE), INACTIVE_DATE DATE, INACTIVE_DESC VARCHAR2(100 BYTE), UNWINDING_DATE DATE, START_DATE_UNWINDING_INTEREST DATE, DUE_DATE_UNWINDING_INTEREST DATE, BALANCE_BEFORE_IIP FLOAT(126), BALANCE_AFTER_IIP FLOAT(126), IIP_AMOUNT FLOAT(126), UNWINDING_FLAG CHAR(1 BYTE), INPUT_SOURCE VARCHAR2(4 BYTE), SOURCE_FLAG CHAR(1 BYTE), TTL_GROSS_PROCEED NUMBER(19,4), TTL_UNWIND_INTEREST NUMBER(19,4), PKID NUMBER(19), TTL_NPV NUMBER(19,4), CREATEDBY VARCHAR2(50 BYTE), CREATEDDATE TIMESTAMP(3), UPDATEDBY VARCHAR2(50 BYTE), UPDATEDDATE TIMESTAMP(3), ASSUMPTION VARCHAR2(500 BYTE)

7. Proses Ekstraksi File PSAK_DPD_MASTER ke Tabel

Tabel 4.34 Struktur Tabel PSAK_DPD_MASTER

Nama Field Data Type DPD_ID INTEGER, DPD_NAME VARCHAR2(50 BYTE), BI_PROV_RATE INTEGER, DPD_ORDER INTEGER, FLOW_RATE_NAME VARCHAR2(50 BYTE), COMPOUND_LOSS_NAME VARCHAR2(50 BYTE), DPD_START INTEGER, DPD_END INTEGER,


121


Nama Field Data Type PRODUCT_GROUP VARCHAR2(50 BYTE), FLAG_DEFAULT CHAR(1 BYTE)DEFAULT 0, PD_DEFAULT NUMBER(9,6) DEFAULT 0

8. Proses Ekstraksi File PSAK PSAK_DPD_MASTER_HEADER ke Tabel

Tabel 4.35 Struktur Tabel PSAK_DPD_MASTER_HEADER

Nama Field Data Type PRODUCT_GROUP VARCHAR2(20 BYTE), PRODUCT_GROUP_DESCRIPTION VARCHAR2(100 BYTE), CALCULATION_TYPE CHAR(1 BYTE), METHOD_IMPAIRMENT CHAR(6 BYTE), HISTORICAL_DATA NUMBER(10), PRODUCT_GROUP_PARENT VARCHAR2(20 BYTE), RANGE_START NUMBER(9,6), RANGE_END NUMBER(9,6), PD_THRESHOLD NUMBER(9,6), IA_FLAG VARCHAR2(1 BYTE) DEFAULT 0,

OPTION_GROUPING VARCHAR2(3 BYTE) DEFAULT 'DPD',

CALC_METHOD CHAR(1 BYTE), INCREMENTS INTEGER, INDIV_ASSESMENT VARCHAR2(1 BYTE), LGD_METHOD VARCHAR2(5 BYTE)

4.4.1.3 Tranformasi Data CKPN

Untuk mendapatkan data final CKPN diperlukan proses transformasi antara lain ;

penerapan business rule, pembersihan data (misalnya melakukan exclude

segmentasi yang NULL), melakukan filter, melakukan update dan melakukan join

dari berbagai tabel sumber untuk proses perhitungan sesuai dengan analisa

business requirement pada bagan alur proses transformasi perhitungan CKPN.

Proses transformasi yang dilakukan dibedakan menjadi 4 langkah proses, sesuai

dengan Gambar 4.6:


122


Gambar 4.6 Overal Proses Transformasi Perhitungan Impairment (CKPN)

1. SP_PSAK_INDIVIDUAL_IMPAIRMENT ; Proses ini akan melakukan flag

Impairment Individual dan mengupdate nilai dari CKPN Individual.

a. UPDATE Tabel PSAK_MASTER_ACCOUNT, field IMPAIRED_FLAG

= ‘I’ dengan join Data Individual Impairment pada nama ekstrak

PSAK_IMPR_OVERRIDES dengan join kondisi Customer Number

antara kedua tabel tersebut.

b. Update Tabel PSAK_MASTER_ACCOUNT, field IIP_AMOUNT dan

UNWINDING_AMOUNT dari tabel sumber PSAK_INDIVIDUAL_

IMPAIRMENT dan TBLT_PAYMENTEXPECTED dengan kondisi join

MASTER_ACCOUNT_ID, IMP_STATUS=’A’ dan PAYMENTDATE

adalah tanggal akhir bulan, IMPAIRED_FLAG=’I’

2. SP_PSAK_CALC_LGD :Proses yang akan melakukan transformasi

perhitungan Nilai LGD untuk kedua metodologi perhitungan LGD (Expected

Recoveries dan Collateral Shortfal), dimana data-data yang digunakan adalah

data dari ekstrak PSAK_EXPECTED_RECOV_UPLOAD dan

PSAK_COLL_SHORTFALL_UPLOAD. Semua hasil perhitungan final LGD

ini akan diinsert ke tabel PSAK_RECOVERY_MATRIX. Tabel

PSAK_RECOVERY_MATRIX merupaakan Tabel yang disiapkan untuk

menampung hasil proses transformasi untuk perhitungan nilai LGD berisi nilai

final LGD (1-recovery rate)


123


3. SP_PSAK_CALC_CA : Proses yang akan melakukan transformasi dalam

Menghitung nilai Probability of Default (PD) dengan menggunakan metode

Net Flow Rate dan Migration Analysis. Proses ini dibagi menjadi 3 bagian

yaitu :

a. UPDATE attribute Collective Assesment di Tabel

PSAK_MASTER_ACCOUNT pada field PRODUCT_GROUP, DPD_ID,

IMPAIRED_FLAG=’C’. Untuk PRODUCT_GROUP dan DPD_ID akan

diupdate berdasarkan tabel Input PSAK_BMI_SEGMENT

,PSAK_DPD_MASTER, PSAK_DPD_MASTER_HEADER. Proses

selanjutnya adalah melakukan insert ke tabel PSAK_ENR. Tabel 4.36

menjelaskan proses transformasi ke tabel tujuan tabel PSAK_ENR

Tabel 4. 36 Tabel Transformasi PSAK_ENR

Source Destination Remarks

PSAK_MASTER_ACCOUNT.DPD_I

D

PSAK_ENR.DPD_ID

PSAK_MASTER_ACCOUNT.PROD

UCT_GROUP

PSAK_ENR.PRODUCT

_GROUP

PSAK_MASTER_ACCOUNT.DOWN

LOAD_DATE

PSAK_ENR.PERIOD

PSAK_MASTER_ACCOUNT.OUTST

ANDING


EXCHANGE_RATE

PSAK_ENR.AMOUNT SUM(OUTSTANDING *

NVL(EXCHANGE_RATE, 1))

PSAK_ENR.ACCOUNT NVL(COUNT(1), 0) AS NOA

Conditions:

Join PSAK_MASTER_PRODUCT_PARAMETER on PMA.DATA_SOURCE = PRD.DATA_SOURCE

AND PMA.PRODUCT_CODE = PRD.PRD_CODE AND PMA.PRODUCT_TYPE = PRD.PRD_TYPE

JOIN PSAK_DPD_MASTER DPD_D ON PMA.DPD_ID = DPD_D.DPD_ID AND

PMA.PRODUCT_GROUP = DPD_D.PRODUCT_GROUP JOIN PSAK_DPD_MASTER_HEADER

DPD_HON PMA.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP AND

DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A' AND

PMA.OUTSTANDING > 0 AND NVL(PMA.IS_IMPAIRED, ' ') = 'Y' AND

NVL(PMA.WRITE_OFF_FLAG, ' ') <> 'Y' AND NVL(PMA.PRODUCT_GROUP, ' ') <> ' ' AND

DPD_H.IA_FLAG = '0'


124


b. Perhitungan PD dengan menggunakan Net Flow Rate. Akan dilakukan 3

sub proses perhitungan Flow rate mengacu kepada Business Requirement

yang terdiri dari :

i. Proses Perhitungan Flowrate SP_PSAK_CALC_FLOWRATES, flow

prosesnya adalah insert ke tabel temporary untuk periode bulan ini dan

insert ke temporary untuk periode bulan sebelumnya, dimana

sumbernya berasal dari tabel PSAK_ENR. Rumus atau transformasi

dalam menghitung Flow Rate adalah outstanding bulan ini dibagi

dengan outstanding bulan lalu dengan DPD_Bucket yang berbeda.

Outstanding DPD Bucket ke-2 dibagi dengan Outstanding DPD Bucket

ke-1. Output transformasi pada tabel PSAK_FLOW_RATES. Tabel

4.37 dibawah ini merupakan tabel transformasi PSAK_LGD.

Tabel 4.37 Tabel Transformasi PSAK_LGD (Flow Rate Calculation)


PSAK_DPD_MASTER.DPD_ID DPD_ID

PSAK_DPD_MASTER.PRODUCT_G

ROUP

PRODUCT_GROUP

TYPE DEFAULT ‘O’

PSAK_ENR.PERIOD PERIOD

PSAK_ENR FLOW_RATES CASE WHEN NVL

(DPD_M.FLAG_DEFAULT, '0')

= 'Y' THEN

PD_M.PD_DEFAULT / 100

WHEN

NVL

(DPD_H.PD_THRESHOLD, 0)

<> 0 AND NVL

(A1.FLOW_RATES, 0) > NVL

(DPD_H.PD_THRESHOLD, 0) /

100 THEN

DPD_H.PD_THRESHOLD / 100

ELSE A1.FLOW_RATES


125


Conditions:

FROM ( SELECT MASTER.DPD_ID, MASTER.PRODUCT_GROUP, DPD.PERIOD, DPD.TYPE,

DPD.FLOW_RATES FROM PSAK_DPD_MASTER MASTER LEFT OUTER JOIN (SELECT NVL

(A.DPD_ID,(B.DPD_ID - 1)) AS DPD_ID, B.PRODUCT_GROUP, 'O' AS TYPE,

B.PERIOD, CASE WHEN NVL (A.AMOUNT, 0) <> 0 THEN NVL (B.AMOUNT, 0) / NVL

(A.AMOUNT, 0) WHEN NVL (A.AMOUNT, 0) = 0 THEN 0 END AS FLOW_RATES FROM

PSAK_ENR B LEFT JOIN PSAK_ENR A ON A.DPD_ID = (B.DPD_ID - 1) AND

A.PRODUCT_GROUP = B.PRODUCT_GROUP AND A.PERIOD = FUTIL_ADD_PERIOD

(B.PERIOD, -1) WHERE A.AMOUNT IS NOT NULL AND B.PERIOD = V_PERIOD AND

B.DPD_ID > 1 AND A.PERIOD IS NOT NULL) DPD ON MASTER.DPD_ID = DPD.DPD_ID

AND MASTER.PRODUCT_GROUP = DPD.PRODUCT_GROUP ORDER BY

MASTER.PRODUCT_GROUP, MASTER.DPD_ID) A1 INNER JOIN PSAK_DPD_MASTER

DPD_M ON DPD_M.PRODUCT_GROUP = A1.PRODUCT_GROUP AND DPD_M.DPD_ID =

A1.DPD_ID INNER JOIN PSAK_DPD_MASTER_HEADER DPD_H ON

DPD_H.PRODUCT_GROUP = DPD_M.PRODUCT_GROUP WHERE DPD_M.PRODUCT_GROUP

IN (SELECT PRODUCT_GROUP FROM PSAK_DPD_MASTER_HEADER WHERE

METHOD_IMPAIRMENT = 'S00031' AND CALCULATION_TYPE = 'A') ORDER BY

PRODUCT_GROUP, PERIOD, DPD_ID;

ii. Proses Perhitungan Average Net flowrate. Output transformasinya adalah

di Tabel PSAK_COMPOUND_FLOW_TO_LOSS . Yang menjadi sumber

tabel input adalah PSAK_FLOW_RATES, PSAK_DPD_MASTER_

HEADER, dan PSAK_DPD_MASTER. Tabel 4.38 mengenai transformasi

dari tabel sumber ke tabel tujuan PSAK_LGD

Tabel 4.38 Tabel Transformasi PSAK_LGD (Average Flow Rate)


PSAK_FLOW_RATES.DPD_ID DPD_ID

PSAK_FLOW_RATES.PRODUCT_G

ROUP

PRODUCT_GROUP

PSAK_FLOW_RATES.TYPE TYPE DEFAULT ‘O’

PSAK_FLOW_RATES.PERIOD PERIOD

PSAK_FLOW_RATES.FLOW_RATE

S

FLOW_TO_LOSS AVG (FLOW_RATES)


126


Conditions:

FROM PSAK_FLOW_RATES rates INNER JOIN ( SELECT a.product_group, b.dpd_id,

V_PERIOD AS period, AVG (b.FLOW_RATES) AS FLOW_TO_LOSS FROM

PSAK_DPD_MASTER_HEADER a INNER JOIN PSAK_DPD_MASTER DPD_M ON

A.PRODUCT_GROUP = DPD_M.PRODUCT_GROUP INNER JOIN PSAK_FLOW_RATES b ON

a.product_group = b.product_group AND DPD_M.DPD_ID = B.DPD_ID WHERE

METHOD_IMPAIRMENT = 'S00031' AND CALCULATION_TYPE = 'A' AND PERIOD

BETWEEN TO_CHAR (ADD_MONTHS ( LAST_DAY (TO_DATE ( SUBSTR (V_PERIOD, 1, 4) ||

'-' || SUBSTR (V_PERIOD, 5, 2) || '-' || '01', 'YYYY-MM-DD')), (-1 * (a.historical_data)) + 1),

'YYYYMM') AND V_PERIOD GROUP BY a.product_group, b.dpd_id) dpd ON

RATES.PRODUCT_GROUP = dpd.product_group AND rates.period = dpd.period AND rates.dpd_id

= dpd.dpd_id ORDER BY rates.PRODUCT_GROUP, rates.DPD_ID;

iii. Proses perhitungan Average PD dan LGD Flowrate. Job yang

menghandel transformasi ini adalah stored procedure

SP_PSAK_CALC_LGD_NETFLOWRATE. Hasil trasformasi ini akan

ditampung di tabel PSAK_LGD dengan menggunakan berbagai sumber

tabel yaitu PSAK_COMPOUND_FLOW_TO_LOSS,

PSAK_DPD_MASTER_ HEADER, PSAK_DPD_MASTER, dan tabel

PSAK_RECOVERY_ MATRIX. Tabel 4.39 menjelaskan transformasi

dari beberapa tabel sumber ke tabel tujuan PSAK_LGD.

Tabel 4. 39 Tabel Transformasi PSAK_LGD (Flow To Loss Calculation) Source Destination Remarks

PSAK_DPD_MASTER DPD_ID

PSAK_COMPOUND_FLOW_TO_LO

SS

PRODUCT_GROU

P


SS

PERIOD


127




SS

PD CASE WHEN

NVL(DPD_D.FLAG_DEFAULT, '0') =

'Y' THEN DPD_D.PD_DEFAULT / 100

ELSE

CASE COUNT(CASE

SIGN(FTL.FLOW_TO_LOSS) WHEN 0

THEN 1 ELSE NULL END)

CASE MOD(SUM(CASE

SIGN(FTL.FLOW_TO_LOSS) WHEN -

1 THEN 1 ELSE 0 END), 2) WHEN 1

THEN -1 -- ODD NUMBER OF

NEGATIVE NUMBERS: RESULT

WILL BE NEGATIVE ELSE 1 --

EVEN NUMBER OF NEGATIVE

NUMBERS: RESULT WILL BE

POSITIVE END * -- MULTIPLY -1 OR

1 WITH THE FOLLOWING

EXPRESSION EXP(SUM(LN( -- ONLY

POSITIVE (NON-ZERO) VALUES!

ABS(CASE FTL.FLOW_TO_LOSS

WHEN 0 THEN NULL ELSE

FTL.FLOW_TO_LOSS END)))) ELSE 0

-- THERE WERE ZEROES, SO THE

ENTIRE PRODUCT IS 0, TOO. END

END

PSAK_RECOVERY_MATRIX.RECO

VERY_RATE

LGD 1 – ISNULL(RECOVERY_RATE, 0)

Conditions:

FROM PSAK_COMPOUND_FLOW_TO_LOSS FTL INNER JOIN PSAK_DPD_MASTER_HEADER

DPD_H ON

FTL.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP INNER JOIN PSAK_DPD_MASTER DPD_D

ON FTL.PRODUCT_GROUP = DPD_D.PRODUCT_GROUP AND DPD_D.DPD_ID <= FTL.DPD_ID

LEFT OUTER JOIN PSAK_RECOVERY_MATRIX MAT ON FTL.PERIOD = MAT.PERIOD AND

FTL.PRODUCT_GROUP = MAT.PRODUCT_GROUP WHERE FTL.PERIOD = V_PERIOD AND

DPD_H.METHOD_IMPAIRMENT = 'S00031' AND DPD_H.CALCULATION_TYPE = 'A' GROUP BY

DPD_D.DPD_ID, FTL.PRODUCT_GROUP, FTL.PERIOD, MAT.RECOVERY_RATE,

DPD_D.FLAG_DEFAULT, DPD_D.PD_DEFAULT;


128


c. Perhitungan PD dengan menggunakan Migration Analysis akan dilakukan 4

sub proses transformasi yaitu terdiri dari :

i. Transformasi untuk membuat snapshot pergerakan masing-masing

account dan sum of outstanding dari kolektibilitas 1 ke kolektibilitas yang

lebih tinggi dengan membandingkan data pada periode bulan ini dan data

pada periode bulan sebelumnya. Sumber tabel yang digunakan adalah

PSAK_MASTER_ACCOUNT. Hasil trasformasi ini akan diletakkan pada

di tabel PSAK_ENR_MIGRATION. Sub Proses pertama ini di-manage

oleh stored procedure SP_PSAK_CALC_ENR_MA. Proses

transformasinya dapat dilihat pada Tabel 4.40

Tabel 4.40 Tabel Transformasi PSAK_ENR_MIGRATION


PSAK_MASTER_ACCOUNT DPD_ID_FROM Periode bulan sebelumnya

PSAK_MASTER_ACCOUNT PERIOD_FROM Periode bulan sebelumnya

PSAK_MASTER_ACCOUNT DPD_ID_TO Periode bulan pelaporan

PSAK_MASTER_ACCOUNT PERIOD_TO Periode bulan pelaporan

PSAK_MASTER_ACCOUNT PRODUCT_GROUP

PSAK_MASTER_ACCOUNT TOTAL_ACCOUNT COUNT (Account_Number)

PSAK_MASTER_ACCOUNT SUMMARY_OUTSTA

NDING

SUM(Outstanding *

Exchange_Rate)

Conditions:

SELECT A.PRODUCT_GROUP, TO_CHAR(A.DOWNLOAD_DATE, 'YYYYMM') AS

PERIOD_FROM, V_PERIOD AS PERIOD_TO, A.DPD_ID AS DPD_FROM, CASE WHEN

NVL(B.DPD_ID, 0) = 0 THEN CASE WHEN B.WRITE_OFF_FLAG = 'Y' THEN

DPD_D.MAX_DPD_ID ELSE DPD_D.MIN_DPD_ID END ELSE B.DPD_ID END AS DPD_TO, -

-NVL(B.DPD_ID, A.DPD_ID) AS DPD_TO, NVL(B.OUTSTANDING, 0) *

NVL(B.EXCHANGE_RATE,1)AS OUTSTANDING FROM TT_ACCOUNT_MIGRATION_HIST

A INNER JOIN PSAK_DPD_MASTER_HEADER DPD_H ON A.PRODUCT_GROUP =

DPD_H.PRODUCT_GROUP INNER JOIN (SELECT PRODUCT_GROUP, MIN(DPD_ID) AS

MIN_DPD_ID, MAX(DPD_ID) AS MAX_DPD_ID FROM PSAK_DPD_MASTER GROUP BY

PRODUCT_GROUP) DPD_D ON A.PRODUCT_GROUP = DPD_D.PRODUCT_GROUP LEFT

OUTER JOIN TT_ACCOUNT_MIGRATION_CURR B ON A.MASTER_ACCOUNT_ID =

B.MASTER_ACCOUNT_ID WHERE DPD_H.IA_FLAG = '1') X GROUP BY X.DPD_FROM,

X.PERIOD_FROM, X.DPD_TO, X.PERIOD_TO, X.PRODUCT_GROUP;


129


ii. Dari hasil snapshot pergerakan account untuk masing-masing

kolektibilitas tersebut, kemudian dilakukan transformasi untuk menghitung

Flow Rate movement kolektibilitasnya. Sumber tabel yang digunakan

untuk proses transformasi ini adalah PSAK_ENR_MIGRATION dan

PSAK_DPD_MASTER_HEADER. Dimana hasil transformasi ini akan

diletakkan pada tabel PSAK_FLOWRATE_MIGRATION. Sub Proses

ke-2 ini di lakukan oleh stored procedure SP_PSAK_CALC_

FLOWRATE_MA. Tabel 4.41 menjelaskan proses transformasi ke tabel

tujuan PSAK_FLOWRATE_MIGRATION

Tabel 4.41 Tabel Transformasi PSAK_FLOWRATE_MIGRATION


PSAK_ENR_MIGRATION DPD_ID_FROM Periode bulan sebelumnya

PSAK_ENR_MIGRATION PERIOD_FROM Periode bulan sebelumnya

PSAK_ENR_MIGRATION DPD_ID_TO Periode bulan pelaporan

PSAK_ENR_MIGRATION PERIOD_TO Periode bulan pelaporan

PSAK_ENR_MIGRATION PRODUCT_GROUP

PSAK_ENR_MIGRATION FLOW_RATES SUMMARY_OUTSTANDI

NG (bulan pelaporan) /

SUMMARY_OUTSTANDI

NG (bulan sebelumnya)

Conditions:

FROM PSAK_ENR_MIGRATION ENR

INNER JOIN PSAK_DPD_MASTER_HEADER DPD_H

ON ENR.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP

WHERE ENR.PERIOD_TO = V_PERIOD;

iii. Dari hasil perhitungan flow rate migration tersebut, kemudian akan

dihitung probability default dari masing-masing kolektibilitas, mulai dari

kolektibilitas 1 sampai dengan kolektibilitas 5. Sumber tabel yang

digunakan sebagai input adalah PSAK_FLOWRATE_MIGRATION,

PSAK_DPD_MASTER. Hasil transformasi ini diletakkan pada tabel

PSAK_COMPOUND_FLOW_TO_LOSS. Stored Procedure yang

digunakan dalam sub proses ke-3 ini adalah

SP_PSAK_CALC_FLOWTOLOSS_MA. Tabel 4.42 menjelaskan proses


130


transformasi perhitungan PD ke tabel tujuan

PSAK_COMPOUND_FLOW_TO_LOSS.

Tabel 4.42 Tabel Transformasi PSAK_COMPOUND_FLOW_TO_LOSS Source Destination Remarks


PSAK_FLOWRATE_MIGRATION PRODUCT_GROUP

TYPE Default ‘O’

PSAK_FLOWRATE_MIGRATION PERIOD

PSAK_FLOWRATE_MIGRATION FLOW_TO_LOSS

Conditions: N/A

Setelah masing-masing probability of default (PD) ini diketahui maka selanjutnya

akan dilakukan rata-rata PD di masing-masing period dari hasil transformasi point

c.3 diatas selama 36 bulan terakhir untuk setiap kolektibilitas. Tabel Sumber

adalah tabel PSAK_COMPOUND_FLOW_TO_LOSS,

PSAK_DPD_MASTER_HEADER, PSAK_DPD_MASTER, PSAK_

RECOVERY_MATRIX dan hasil transformasi ini akan diletakkan pada tabel

PSAK_LGD. Stored Procedure yang menghandel sub proses ke-4 ini adalah

SP_PSAK_CALC_LGD_MA. Tabel 4.43 menjelaskan transformasi proses

perhitungan LGD.

Tabel 4.43 Tabel Transformasi PSAK_LGD



PSAK_COMPOUND_FLOW_TO_LOSS PRODUCT_GR

OUP

PSAK_COMPOUND_FLOW_TO_LOSS PERIOD

PSAK_COMPOUND_FLOW_TO_LOSS PD CASE WHEN

NVL(DPD_D.FLAG_DEFAULT, '0') =

'Y' THEN

NVL(DPD_D.PD_DEFAULT, 0) / 100

ELSE

AVG(NVL(FL.FLOW_TO_LOSS, 0))

END AS PD

PSAK_RECOVERY_MATRIX.

RECOVERY_RATE

LGD 1 - NVL(MAT.RECOVERY_RATE, 0)

AS LGD


131


Conditions:

FROM PSAK_DPD_MASTER DPD_D INNER JOIN PSAK_DPD_MASTER_HEADER DPD_H ON

DPD_D.PRODUCT_GROUP = DPD_H.PRODUCT_GROUP AND DPD_H.METHOD_IMPAIRMENT

= 'S00033' AND DPD_H.CALCULATION_TYPE = 'A' INNER JOIN

PSAK_COMPOUND_FLOW_TO_LOSS FL ON DPD_D.PRODUCT_GROUP =

FL.PRODUCT_GROUP AND FL.DPD_ID = DPD_D.DPD_ID LEFT JOIN

PSAK_RECOVERY_MATRIX MAT ON FL.PRODUCT_GROUP = MAT.PRODUCT_GROUP AND

MAT.PERIOD = V_PERIOD WHERE FL.PERIOD BETWEEN

TO_CHAR(ADD_MONTHS(TO_DATE(V_PERIOD, 'YYYYMM'), DPD_H.HISTORICAL_DATA * -

1), 'YYYYMM') AND V_PERIOD AND LAST_DAY(TO_DATE(FL.PERIOD, 'YYYYMM')) >=

V_CUTOFF_DATE GROUP BY DPD_D.DPD_ID, DPD_D.PRODUCT_GROUP,

DPD_D.FLAG_DEFAULT, DPD_D.PD_DEFAULT, MAT.RECOVERY_RATE;

4. SP_PSAK_POST_PROCESS_CA : Proses transformasi update semua hasil

kalkulasi ke tabel PSAK_MASTER_ACCOUNT untuk field berikut ini yaitu

PD_RATE, LGD_RATE, PIP_AMOUNT, UNWINDING_AMOUNT,

BEGINNING_BALANCE, CHARGE, WRITEBACK, ENDING_BALANCE

Tabel 4.44 menjelaskan rincian proses transformasi ke tabel tujuan

PSAK_MASTER_ACCOUNT

Tabel 4. 44 Tabel Transformasi PSAK_MASTER_ACCOUNT

Source Destination Rules

PSAK_LGD PD_RATE

PSAK_LGD LGD_RATE

PSAK_LGD PIP_AMOUNT OUTSTANDING * PD_RATE *

LGD_RATE * LIP

PSAK_MASTER_ACCOU

NT

UNWINDING_AMOU

NT

(NVL(PMA.OUTSTANDING, 0) -

NVL(PMA.PIP_AMOUNT, 0)) *

(DECODE(NVL(PMA.EIR, 0), 0,

NVL(PMA.INTEREST_RATE, 0),

NVL(PMA.EIR, 0)) / 100 / 12)

PSAK_MASTER_ACCOU

NT

BEGINNING_BALAN

CE

ENDING_BALANCE (PREVIOUS

PERIOD)


132


Source Destination Rules

PSAK_MASTER_ACCOU

NT

CHARGE CASE WHEN

NVL(PREV.ENDING_BALANCE, 0) <

CASE WHEN CUR.IMPAIRED_FLAG = 'I'

THEN

NVL(CUR.IIP_AMOUNT, 0) ELSE

NVL(CUR.PIP_AMOUNT, 0) END THEN

CASE WHEN

CUR.IMPAIRED_FLAG = 'I' THEN


NVL(CUR.PIP_AMOUNT, 0)

END - NVL(PREV.ENDING_BALANCE,

0) ELSE 0 END AS CHARGE

PSAK_MASTER_ACCOU

NT

WRITEBACK CASE WHEN

NVL(PREV.ENDING_BALANCE, 0) >

CASE WHEN CUR.IMPAIRED_FLAG = 'I'

THEN


NVL(CUR.PIP_AMOUNT, 0) END THEN

CASE WHEN

CUR.IMPAIRED_FLAG = 'I' THEN


NVL(CUR.PIP_AMOUNT, 0)

END - NVL(PREV.ENDING_BALANCE,

0) ELSE 0 END AS WRITEBACK,

PSAK_MASTER_ACCOU

NT

ENDING_BALANCE CASE WHEN CUR.IMPAIRED_FLAG = 'I'

THEN NVL(CUR.IIP_AMOUNT, 0) ELSE

NVL(CUR.PIP_AMOUNT, 0)END AS

ENDING_BALANCE

4.4.2 Proses Transformasi dan Load Tabel Dimensi

Pada bagian ini akan dijelaskan bagaiman proses transformasi yang berkaitan

dengan semua tabel dimensi. Proses Transformasi dan Load pada tabel dimensi

dibedakan berdasarkan Type dari SCD per masing-masing tabel dimensi. Proses

transformasi dan Load untuk semua tabel dimensi merupakan proses mandatory

sebelum proses load ke tabel Fakta.


133


4.4.2.1 Load Slowly Changing Dimension (SCD) Type 0

Semua dimensi dengan SCD Type 0 hanya akan dijalankan sekali pada saat initial

setup PSAK Datamart. Hal tersebut karena tipe dimensi SCD Type 0 merupakan

fixed attribute yang durable yang tidak pernah berubah. Source data yang

digunakan berupa Flat file excel files. Gambar berikut ini akan menjelaskan

proses Load ke masing-masing tabel dimension dengan SCD Type 0 yang terdiri

dari dimensi berikut: DIM_PERIOD, DIM_AKAD, DIM_CURRENCY,

DIM_COLLECTIBILITY, DIM_COLLECTIBILITY_MOVEMENT dan

DIM_IMPAIRMENT_FLAG.

4.4.2.2 Transformasi dan Load Slowly Changing Dimension (SCD) Type 1

Untuk menghasilkan record di tabel Dimensi Customer, dilakukan dengan

mengambil data dari tabel sumber PSAK_MASTER_ACCOUNT dan melakukan

import ke dalam tabel DIM_CUSTOMER. Proses load dimensi ini dilakukan

selama sebulan sekali pada saat periode pelaporan. Penjelasan mengenai atribut

apa saja yang digunakan dijelaskanpada tabel 4.45

Tabel 4.45 Tabel Sumber, Tujuan dan Rules Dimensi Customer

Tabel Sumber Tabel Tujuan/Field Name/Data Type

Rules Initial Load dan Update

DIM_CUSTOMER. CUSTOMER_SK

Merupakan Surrogate Key dari Code Customer Number


CUSTOMER_NUMBER

DIM_CUSTOMER. CUSTOMER_NUMBER


GLOBAL_CUSTOMER_NUMBER,

DIM_CUSTOMER.

GLOBAL_CUSTOMER_NUMBER

Attribute yang akan diupdate apabila terdapat perubahan (SCD Type 1)


CUSTOMER_NAME,

DIM_CUSTOMER.

CUSTOMER_NAME



134


Tabel Sumber Tabel Tujuan/Field Name/Data Type



CUSTOMER_GRADE

DIM_CUSTOMER.

CUSTOMER_GRADE


CREATEDDATE SYSTEM DATE pada saat setiap kali insert apabila terdapat new records

UPDATEDDATE System Date pada setiap adanya perubahan

4.4.2.3 Transformasi dan Load Slowly Changing Dimension (SCD) Type 2

Sesuai dengan pembahasan pada sub bab 4.3.8, maka pada bagian proses ETL ini

akan dijelaskan porses Load Dimensi-dimensi SCD Type 2. SCD Type-akan

menambahkan record baru untuk setiap perubahan dan original record akan tetap

tersimpan pada tabel dimensi. Dimensi yang termasuk dalam SCD Type 2 adalah

Dimensi Segment, Dimensi Impairment Group, Dimensi Area, Dimensi Main

Branch, Dimensi Branch, Dimensi Product, dan Dimensi Maturity Profile

Proses Load Dimensi Segment (DIM_SEGMENT)

Untuk menghasilkan record terhadap tabel Dimensi Segment, dilakukan dengan

mengambil data dari tabel sumber PSAK_BMI_SEGMENT dan melakukan

import ke dalam tabel DIM_SEGMENT. Penjelasan mengenai atribut apa saja

yang digunakan dijelaskanpada tabel 4.46


135


Tabel 4. 46 Tabel Sumber, Tujuan dan Rules Dimensi Segment

Tabel Sumber / Nama

Field

Tabel Tujuan/Field

Name/Data Type Rules Initial Load dan Update

SEGMENT_KEY Merupakan Surrogate Key dari kode segment, incremental 1

SEGMENT_LEVEL_1_CODE Sequence

PSAK_BMI_SEGMENT.

COLLECTIVE_GROUP_4

SEGMENT_LEVEL_1_DESC

Apabila ada perubahan maka dilakukan insert new record untuk memaintain data history (SCD Type 2)

SEGMENT_LEVEL_2_CODE Sequence

PSAK_BMI_SEGMENT.

SEGMENT_BMI



SEGMENT_LEVEL_3_CODE LEFT(C09_SEGMENTASI_ACCOUNT,2)

PSAK_BMI_SEGMENT.

C09_SEGMENTASI_ACCOUNT



START_DATE SYSTEM DATE pada saat setiap kali insert atau perubahan data apabila terdapat new records

END_DATE

Untuk Old Record : akan diisi dengan System Date pada setiap adanya perubahan. Sedangkan untuk New Record : akan diisi dengan value date 31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut aktif dimana value pada END_DATE adalah 31-12-9999

Proses Load Dimensi Impairment Group (DIM_IMPAIRMENT_GROUP)

Untuk menghasilkan record terhadap tabel Dimensi Impairment Group,

dilakukan load dari tabel sumber PSAK_BMI_SEGMENT dan melakukan import

ke dalam tabel DIM_IMPAIRMENT_GROUP dengan Distinct Value dari


136


PSAK_BMI_SEGMENT field COLLECTIVE_GROUP_2. Penjelasan mengenai

atribut apa saja yang digunakan dijelaskanpada tabel 4.47

Tabel 4.47 Tabel Sumber, Tujuan, dan Rules Dimensi Impairment Group

Tabel Sumber / Nama

Field

Tabel Tujuan/Field

Name/Data Type


IMPAIRMENT_CODE Merupakan Surrogate Key dari kode

Impairment Code, incremental 1

PSAK_BMI_SEGMENT.

COLLECTIVE_GROUP_

4

IMPAIRMENT_GROUP

Distinct COLLECTIVE_GROUP_4

FROM PSAK_BMI_SEGMENT).

Apabila ada perubahan maka dilakukan

insert new record untuk memaintain

data history (SCD Type 2)

START_DATE SYSTEM DATE pada saat setiap kali

insert atau perubahan dataatau apabila

terdapat new records

END_DATE Untuk Old Record : akan diisi dengan

System Date pada setiap adanya

perubahan. Sedangkan untuk New

Record : akan diisi dengan value date

31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut

aktif dimana value pada END_DATE

adalah 31-12-9999

Proses Load Dimensi Area (DIM_AREA)

Untuk menghasilkan record terhadap tabel Dimensi Area, dilakukan

load data dari tabel sumber MASTER_BRANCH dan melakukan import ke dalam

tabel DIM_AREA. Penjelasan mengenai atribut apa saja yang digunakan

dijelaskanpada tabel 4.48


137


Tabel 4.48 Tabel Sumber, Tujuan, dan Rules Dimensi Area (DIM_AREA)

Tabel Sumber / Nama

Field

Tabel Tujuan/Field

Name/Data Type


AREABRANCH_SK Merupakan Surrogate Key dari kode Area

Code, incremental 1

MASTER_BRANCH.

AREA_CODE

AREA_CODE Code ini akan diambil dari Master Area

MASTER_BRANCH.

AREA_DESCRIPTION

AREA_DESC Apabila ada perubahan maka dilakukan

insert new record untuk memaintain data

history (SCD Type 2)

START_DATE SYSTEM DATE pada saat setiap kali insert

atau perubahan data atau apabila terdapat

new records


System Date pada setiap adanya perubahan.

Sedangkan untuk New Record : akan diisi

dengan value date 31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut aktif

dimana value pada END_DATE adalah 31-

12-9999

Proses Load Dimensi Main Branch (DIM_MAINBRANCH)

Untuk menghasilkan record terhadap tabel Dimensi Main Branch (Cabang

Utama), dilakukan load dari tabel sumber MASTER_BRANCH pada field

MAIN_BRANCH_CODE dan melakukan import ke dalam tabel

DIM_MAINBRANCH. Penjelasan mengenai atribut apa saja yang digunakan

dijelaskan pada tabel 4.49


138


Tabel 4.49 Tabel Sumber, Tujuan, dan Rules Dimensi Cabang Utama

Tabel Sumber / Nama

Field

Tabel Tujuan/Field

Name/Data Type


MAINBRANCH_SK Merupakan Surrogate Key dari kode Area Code,

incremental 1

DIM_AREA.

AREA_CODE

AREABRANCH_SK Code ini merupakan foreign key dari tabel

DIM_AREA

MASTER_BRANCH.

MAIN_BRANCH_COD

E

MAIN_BRANCH_CO

DE

Apabila ada perubahan maka dilakukan insert

new record untuk memaintain data history (SCD

Type 2)

MASTER_BRANCH.

MAIN_BRANCH_DES

CRIPTION

MAIN_BRANCH_NA

ME

Apabila ada perubahan maka dilakukan insert

new record untuk memaintain data history (SCD

Type 2)

START_DATE SYSTEM DATE pada saat setiap kali insert atau

perubahan data atau apabila terdapat new records

END_DATE Untuk Old Record : akan diisi dengan System

Date pada setiap adanya perubahan. Sedangkan

untuk New Record : akan diisi dengan value date

31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut aktif dimana

value pada END_DATE adalah 31-12-9999

Proses Load Dimensi Branch (DIM_BRANCH)

Untuk menghasilkan record terhadap tabel Dimensi Branch, dilakukan dengan

mengambil data dari tabel sumber MASTER_BRANCH pada field

BRANCH_CODE dan BRANCH_NAME, kemudian dilakukan import ke dalam


139


tabel DIM_BRANCH. Penjelasan mengenai atribut apa saja yang digunakan

dijelaskanpada tabel 4.50

Tabel 4.50 Tabel Sumber, Tujuan dan Rules Dimensi Cabang

Tabel Sumber / Nama

Field

Tabel Tujuan/Field

Name/Data Type


BRANCH_SK Merupakan Surrogate Key dari kode

branch Code, incremental 1

DIM_MAINBRANCH MAINBRANCH_SK Code ini merupakan foreign key dari tabel

DIM_MAINBRANCH

DIM_AREA AREABRANCH_SK Code ini merupakan foreign key dari tabel

DIM_AREA

BRANCH_CODE Apabila ada perubahan maka dilakukan



BRANCH_NAME Apabila ada perubahan maka dilakukan



START_DATE SYSTEM DATE pada saat setiap kali

insert atau perubahan data atau apabila

terdapat new records


System Date pada setiap adanya

perubahan. Sedangkan untuk New Record

: akan diisi dengan value date 31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut aktif

dimana value pada END_DATE adalah

31-12-9999


140


Proses Load Dimensi Product (DIM_PRODUCT)

Untuk menghasilkan record di tabel Dimensi Product, dilakukan load dari tabel

sumber PSAK_MASTER_PRODUCT_PARAMETER field PRD_TYPE dan field

PRD_CODE, serta tabel MAPPING_PRODUCT_FIN pada field

PRODUCT_NAME. Selanjutnya melakukan import ke dalam tabel

DIM_PRODUCT. Prosesnya dilakukan sebulan sekali pada saat akhir bulan.

Penjelasan mengenai atribut apa saja yang digunakan dijelaskanpada tabel 4.51.

Sedangkan pembaruan data pada Tabel Dimensi Product yaitu ketika terdapat

perubahan data dari sumber data

Tabel 4.51 Tabel Sumber, Tujuan dan Rules Dimensi Product

Tabel Sumber / Nama Field

Tabel Tujuan/Field Name/Data Type


PRODUCT_KEY Merupakan Surrogate Key dari Dimensi Product, incremental 1

PSAK_MASTER_PRODUCT_PARAMETER.PRD_TYPE

AKAD_CODE

PSAK_MASTER_PRODUCT_PARAMETER.PRD_CODE

PRODUCT_CODE Apabila ada perubahan maka dilakukan insert new record untuk memaintain data history (SCD Type 2)

MAPPING_PRODUCT_FIN.PRODUCT_NAME

PRODUCT_NAME Apabila ada perubahan maka dilakukan insert new record untuk memaintain data history (SCD Type 2)

START_DATE SYSTEM DATE pada saat setiap kali insert atau perubahan data atau apabila terdapat new records

END_DATE Untuk Old Record : akan diisi dengan System Date pada setiap adanya perubahan. Sedangkan untuk New Record : akan diisi dengan value date 31-12-9999

FLAG_CURRENT Akan diisi Y apabila record tersebut aktif dimana value pada END_DATE adalah 31-12-9999


141


Proses Load Dimensi Maturity Profile (DIM_MATURITYPROFILE)

Untuk menghasilkan record terhadap tabel Dimensi Maturity Profile, dilakukan

dengan mengambil data dari tabel sumber di flat file excel yang berisi range

pengelompokkan Maturity, dan selanjutnya melakukan import ke dalam tabel

DIM_MATURITYPROFILE. Penjelasan mengenai atribut apa saja yang

digunakan dijelaskanpada tabel 4.52. Pembaruan data pada Tabel Dimensi

MaturityProfile yaitu ketika terdapat perubahan data dari sumber data.

Tabel 4.52 Tabel Sumber, Tujuan, dan Rules Dimensi Maturity Profile

Tabel Sumber / Nama Field

Tabel Tujuan/Field Name/Data Type


Initial load MATURITYPROFILE_SK Merupakan Surrogate Key dari Dimensi Maturity Profile, incremental 1

Initial load DAY_START Merupakan Day Start dari setiap bucket maturity

Initial load DAY_END Merupakan Day End dari setiap bucket maturity

Initial load MATURITYPROFILE_DESC


Initial load START_DATE SYSTEM DATE pada saat setiap kali insert atau perubahan dataatau apabila terdapat new records

Initial load END_DATE

Untuk Old Record : akan diisi dengan System Date pada setiap adanya perubahan. Sedangkan untuk New Record : akan diisi dengan value date 31-12-9999

Initial load FLAG_CURRENT Akan diisi Y apabila record tersebut aktif dimana value pada END_DATE adalah 31-12-9999

4.4.3 Proses Transformasi dan Load ke Tabel Fakta

Setelah selesai melakukan load ke tabel dimensi, maka sebelum melakukan load

ke Tabel Fakta, diperlukan persiapan data agar dilakukan dilakukan transformasi

dengan menyesuaikan tabel dimensi yang sudah dibuat. Hal ini tabel dimensi


142


dijadikan reference untuk mensinkronisasikan antara relationship field di tabel

Fakta dan tabel Dimensi.

4.4.3.1 Transformasi dan Load Fakta Pembiayaan

Sesuai dengan penjelasan diatas bahwa diperlukan persiapan data sebelum

melakukan load ke tabel fakta. Persiapan data yang diperlukan oleh tabel Fakta

Pembiayaan sesuai dengan kebutuhan measurement dan analisa yang dibutuhkan

oleh pengguna, maka diperlukan proses transformasi terhadap informasi-informasi

yang belum tersedia secara raw data dari tabel sumber. Proses transformasi yang

diperlukan sebelum load ke tabel fakta pembiayaan adalah berasal dari beberapa

sumber tabel antara lain :

1. Sumber Tabel PSAK_MASTER_ACCOUNT dengan field

BI_COLLECTABILITY, dengan tujuan tabel FACTLOANACCOUNT, field

BI_KOL. Field-field yang dilakukan transformasi adalah

BI_COLLECTABILITY, dimana format dari sumber tabel adalah numeric,

proses transformasinya adalah melakukan perubahan data type menjadi

character.

2. Field berikutnya adalah KOL_MOV, dimana akan menjelaskan keterangan

pergerakan kolektibilitas untuk setiap account dari satu periode ke periode

berikutnya. Untuk membuat transformasi field ini, langkah awal adalah harus

dilakukan penggabungan semua account number yang terdapat di bulan

pelaporan ini dan account-account pembiayaan yang berasal dari bulan

sebelumnya. Hal ini disebabkan karena ada kemungkinan account pembiayaan

yang sudah mengalami jatuh tempo(matured) atau sudah closed dimana

account tersebut sudah tidak ada lagi di raw data bulan berikutnya. Langkah

ini diperlukan untuk menjawab kebutuhan analisa untuk melihat pergerakan

kolektibilitas per masing-masing cabang. Proses Transformasinya adalah

dengan menggabungkan kolektibilitas bulan pelaporan (Sumber tabel

PSAK_MASTER_ACCOUNT field BI_COLLECTABILITY di tanggal bulan

pelaporan) dengan bulan sebelumnya dengan mengikuti format character

sesuai pada tabel Dimensi DIM_COLLECTIBILITY_MOVEMENT.


143


3. Dari akibat proses transformasi diatas (pergerakan kolektibilitas), maka

diperlukan tambahan satu kolom yaitu FLAG_CURRENT di tabel tujuan

FACTLOANACCOUNT, yaitu akan berisi nilai karakter ‘Y’ atau ‘N’ untuk

identifier bahwa account tersebut merupakan account baru atau account lama.

Flag ‘Y’ menunjukkan bahwa account number tersebut merupakan account

yang ada di bulan pelaporan dan belum ada pada bulan sebelumnya.

4. Field berikutnya adalah field NPL, yaitu dengan mengisi dengan nilai

outstanding apabila account pembiayaan BI_KOL valuenya 3, 4, dan 5.

Setelah dilakukan transformasi pada field NPL (Non Performing Loan), maka

proses transformasi selanjutnya adalah melakukan perhitungan NPL Ratio

dimana merupakan salah satu measurement yang diperlukan pada tabel Fakta

Pembiayaan. Transformasi dilakukan dengan mengelompokkan nilai NPL

setiap cabang kemudian dibagi dengan total Outstanding di setiap cabang

tersebut.

5. Field terakhir yang dilakukan transformasi adalah MaturityID yaitu dengan

menyesuiakan surrogate key yang berada pada tabel Dimensi

DIM_MATURITY_PROFILE sesuai dengan selisih tanggal jatuh tempo (field

: Loan_due_date pada Tabel PSAK_MASTER_ACCOUNT) dengan tanggal

pelaporan dalam satuan hari kalendar yang kemudian dikelompokkan menjadi

kode yang menunjukkan range jatuh tempo pembiayaan.

Tabel 4.53 menjelaskan proses transformasi keseluruhan ke tabel tujuan

FACTLOANACCOUNT

Tabel 4.53 Tabel transformasi FACTLOANACCOUNT sebagai tabel input

sebelum load ke tabel FACT_LOAN Source Destination Remarks

PSAK_MASTER_ACCOUNT.DOWNLOAD_DATE DOWNLOAD_DATE

PSAK_MASTER_ACCOUNT.SEGMENT SEGMENT

PSAK_MASTER_ACCOUNT.CURRENCY CURRENCY

PSAK_MASTER_ACCOUNT. BRANCH_CODE BRANCH_CODE


144


Source Destination Remarks PSAK_MASTER_ACCOUNT. PRODUCT_CODE PRODUCT_CODE

PSAK_MASTER_ACCOUNT. ACCOUNT_NUMBER

ACCOUNT_NUMBER

PSAK_MASTER_ACCOUNT. BI_COLLECTABILITY BI_KOL CONVERT(varchar(1),B.bi_collectability)

AS BI_KOL

KOL_MOV

CASE WHEN CONVERT(varchar(1),A.bi_collectability) IS NULL THEN CONVERT(varchar(1),b.bi_collectability) + '-' + CONVERT(varchar(1),B.bi_collectability) END AS KOL_MOV

FLAG_CURRENT

CASE WHEN CONVERT(varchar(1),A.bi_collectability) IS NULL THEN 'Y' ELSE 'N' end AS FLAG_CURRENT,

PSAK_MASTER_ACCOUNT.OUTSTANDING OUTSTANDING isnull(B.OUTSTANDING,0),

PSAK_MASTER_ACCOUNT.PLAFOND PLAFOND isnull(B.PLAFOND,0),

NPL

CASE WHEN CONVERT(varchar(1),B.bi_collectability) IN ('3','4','5') THEN B.OUTSTANDING ELSE 0 END

PSAK_MASTER_ACCOUNT.LOAN_DUE_DATE MATURITY_ID

CASE WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) < 0 THEN '000' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 0 AND 30 THEN '100' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 31 AND 90 THEN '110' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 91 AND 180 THEN '120' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 181 AND 365 THEN '130' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 365 AND 1095 THEN '140' WHEN DATEDIFF(DAY, B.DOWNLOAD_DATE,B.LOAN_DUE_dATE) BETWEEN 1096 AND 1825 THEN '150' ELSE '160'

Conditions: from #tempPrevMonth A RIGHT JOIN #tempCurrentMonth B ON A.ACCOUNT_NUMBER=B.ACCOUNT_NUMBER


145


Setelah dilakukan pengumpulan data di level granularitas terendah yaitu pada

account number, maka proses selanjutnya adalah melakukan load ke tabel fakta

terakhir yaitu FACT_LOAN. Transformasi per masing-masing field dari sumber

data ke tabel tujuan dapat dilihat pada tabel 4.54

Tabel 4.54 Tabel Load ke Tabel Fakta Pembiayaan (FACT_LOAN)


FACTLOANACCOUNT DOWNLOAD_DATE

DIM_AKAD AKAD_CODE

DIM_SEGMENT SEGMENT_SK

DIM_CURRENCY CURRENCY_CODE

DIM_BRANCH_MASTER AREA_CODE

DIM_BRANCH_MASTER MAIN_BRANCH_CODE

DIM_BRANCH BRANCH_CODE

DIM_COLLECTABILITY BI_COLLECTABILITY

DIM_PRODUCT PRODUCT_CODE

DIM_COLLECTIBILITY_MOVEMENT

COLLECTMOVEMENT_SK

DIM_MATURITYPROFILE MATURITYPROFILE_CODE

FACTLOANACCOUNT OUTSTANDING, SUM(A.OUTSTANDING)

FACTLOANACCOUNT NUMBEROFACCOUNT COUNT(A.ACCOUNT_NUMBER)

FACTLOANACCOUNT PLAFOND SUM(A.PLAFOND)

FACTLOANACCOUNT NONPERFOMINGLOAN SUM(A.NPL)


146



NPL_RATIO UPDATE FACT_LOAN SET NPL_RATIO = B.NPL_RATIO FROM FACT_LOAN AINNER JOIN ( SELECT BRANCH_CODE, SUM(NONPERFOMINGLOAN)/SUM(OUTSTANDING) AS NPL_RATIOFROM FACT_LOAN GROUP BY BRANCH_CODE) B ON A.BRANCH_CODE=B.BRANCH_CODE WHERE A.OUTSTANDING <> 0

Condition:

FACTLOANACCOUNT ALEFT JOIN DIM_BRANCH_MASTER B ON A.BRANCH_CODE=B.BRANCH_CODE LEFT JOIN DIM_SEGMENT C ON A.SEGMENT=C.SEGMENT_LEVEL_3_DESC LEFT JOIN DIM_COLLECTIBILITY_MOVEMENT D ON A.KOL_MOV=D.COLLECTMOVEMENT_DESC GROUP BY A.DOWNLOAD_DATE ,C.SEGMENT_SK ,A.CURRENCY,B.AREA_CODE,B.MAIN_BRANCH_CODE,A.BRANCH_CODE ,A.BI_KOL,A.PRODUCT_CODE,D.COLLECTMOVEMENT_ID,A.MATURITY_ID

4.4.3.2 Transformasi dan Load Fakta CKPN

Persiapan data yang diperlukan sebelum dilakukan load ke tabel fakta CKPN

adalah melakukan pengumpulan data selama dua periode selama dua bulan

pelaporan ke tabel temporary. Data yang dikumpulkan ada pada level akun

pembiayaan. Semua akun pembiayaan dan atribut yang berkaitan dengan

kebutuhan pada fakta CKPN tersebut dikumpulkan di dalam satu tabel.

Tujuan pengumpulan semua data ke dalam satu periode pelaporan terkait dengan

kebutuhan measurementmovement CKPN, yaitu untuk mengetahui berapa banyak

tambahan CKPN yang dibentuk (charged) atau berapa banyak cadangan yang

berkurang (released) di setiap cabang pada periode setiap bulannya. Kebutuhan

lainnya untuk mengetahui pergerakan kolektibilitas dari setiap debitur dari bulan

sebelumnya ke bulan pelaporan.

Transformasi diperlukan juga dalam pembentukan maximum kolektibilitas per

masing-masing customer_number untuk setiap segment, collective impairment

group, currency, branch_code dan product_code.


147


Measurement lainnya adalah variance CKPN aktual dan CKPN forecast terbesar

dan measurement terkait dengan selisih / variance antara pembentukan CKPN dan

PPAP, termasuk didalamnya proses transformasi nilai PPAP. Transformasi nilai

PPAP yaitu dengan mengalikan persentase tertentu untuk masing-masing

maksimum kolektibilitas.

Transformasi lainnya adalah berkaitan dengan proses perhitungan Impaired Loan

Ratio per masing-masing cabang, yang dibentuk dari perbandingan antara nilai

total nilai CKPN dalam mata uang Rupiah pada periode tertentu dibandingkan

dengan total nilai outstanding dalam mata uang Rupiah yang dikelompokkan per

masing-masing cabang (branch_code).

Transformasi diperlukan juga dalam melakukan prorate ke level

customer_number untuk target CKPN dalam mata uang Rupiah (Field :

CKPNFORECAST_IDR), karena yang menjadi data input Target CKPN atau

Forecast adalah dalam level branch, sedangkan data granularitas di tabel

FACT_CKPN adalah di level customer_number.Sumber tabel transformasi Target

CKPN ini adalah pada tabel PSAK_CKPN_TARGET.

Proses transformasi terakhir adalah penyesuaian kode untuk field-field berikut ini

sesuai dengan surrogate key atau primary key pada Tabel Dimensi. Field-field

tersebut adalah AKAD_CODE di Tabel DIM_AKAD, field segment_code di

Tabel DIM_SEGMENT, field IMPAIRMENTGROUP_CODE di Tabel

DIM_IMPAIRMENT_GROUP, field IMPAIRMENT_CODE di Tabel

DIM_IMPAIRMENT_FLAG, field COLLECTMOVEMENT_SK di Tabel

DIM_COLLECTABILITY_MOVEMENT.

Semua output proses transformasi dari masing-masing tabel sumber sebagai

persiapan data sebelum load ke tabel Fakta CKPN ditampung di tabel temporary

FACTCKPNCUST.Rincian transformasi dari sumber data ke tabel tujuan dapat

dilihat pada Tabel 4.55.


148


Tabel 4.55 Tabel Load ke Tabel Fakta CKPN (FACT_CKPN) Source Destination Remarks

FACTCKPNCUST DOWNLOAD_DA

TE

DIM_AKAD AKAD_CODE

DIM_SEGMENT SEGMENT_CODE

FACTCKPNCUST CURRENCY_COD

E

DIM_AREA AREA_CODE

DIM_MAINBRANCH MAIN_BRANCH_

CODE

DIM_BRANCH BRANCH_CODE

DIM_CUSTOMER CUSTOMER_NU

MBER

DIM_PRODUCT PRODUCT_CODE

DIM_IMPAIRMENT_GR

OUP

COLLECTIVE_GR

OUP

FACTCKPNCUST PD_RATE

FACTCKPNCUST LGD_RATE

FACTCKPNCUST EXPECTED_LOSS

_RATE

DIM_IMPAIRMENT_FLA

G

FLAG_IMPAIRED

DIM_COLLECTABILITY

_MOVEMENT

COLLECTMOVE

MENT_SK

CASE WHEN

CONVERT(varchar(1),A.bi_collectability)

IS NULL THEN

CONVERT(varchar(1),b.bi_collectability) +

'-' +

CONVERT(varchar(1),B.bi_collectability)

END AS KOL_MOV

FACTCKPNCUST MAX_BICOLLEC

TABILITY

MAX(BI_COLLECTABILITY) GROUP

BY CUSTOMER_NUMBER

FACTCKPNCUST OUTSTANDING

FACTCKPNCUST COLLATERAL_V

ALUE


149



FACTCKPNCUST PPAP CASE WHEN

MAX(BI_COLLECTABILITY)=1 THEN

SUM(ISNULL(OUTSTANDING,0) *

ISNULL(EXCHANGE_RATE,1) * 0.01)

WHEN MAX(BI_COLLECTABILITY)=2

THEN



WHEN




WHEN MAX(BI_COLLECTABILITY)=4

THEN



WHEN



ISNULL(EXCHANGE_RATE,1) * 1) ELSE

0 END AS PPAP

FACTCKPNCUST CKPNFORECAST SET CKPNFORECAST_IDR =

A.OUTSTANDING_IDR *

B.RATIO_TARGET_CABANG FROM

FACTCKPNCUST A INNER JOIN

(SELECT X.BRANCH_CODE,

X.MAIN_BRANCH_CODE,

X.OUTSTANDING_IDR,

X.CKPNKOLEKTIF_IDR,

X.OUTSTANDING_IDR*Y.impaired_loan_

ratio_per_mainbranch AS

TARGET_BRANCH,

X.CKPNKOLEKTIF_IDR -

(X.OUTSTANDING_IDR*Y.impaired_loan

_ratio_per_mainbranch) AS

VARIANCE,


150



FACTCKPNCUST CKPNFORECAST (X.OUTSTANDING_IDR*Y.impaired_loan

_ratio_per_mainbranch) /

X.OUTSTANDING_IDR AS

RATIO_TARGET_CABANG FROM (

SELECT A.BRANCH_CODE,

B.MAIN_BRANCH_CODE,

SUM(OUTSTANDING_IDR) AS

OUTSTANDING_IDR,

SUM(CKPNKOLEKTIF_IDR) AS

CKPNKOLEKTIF_IDR,

SUM(CKPNKOLEKTIF) AS

CKPNKOLEKTIF,

sum(ckpnkolektif_idr)/sum(outstanding_idr)

as impaired_loan_ratio_per_branch

FROM FACTCKPNCUST A inner join

dim_branch b on a.branch_code =

b.branch_code

GROUP BY A.BRANCH_CODE,

B.MAIN_BRANCH_CODE ) X INNER

JOIN CKPNTARGETIDR Y ON

X.MAIN_BRANCH_CODE=Y.MAIN_BR

ANCH_CODE ) B ON

A.BRANCH_CODE=B.BRANCH_CODE

FACTCKPNCUST CKPNKOLEKTIF

FACTCKPNCUST CKPNINDIVIDUA

L

FACTCKPNCUST INTEREST_UNWI

NDING

FACTCKPNCUST CHARGED

FACTCKPNCUST RELEASED

FACTCKPNCUST IMPAIRED_LOA

N_RATIO


,from (SELECT BRANCH_CODE,

sUM(OUTSTANDING_IDR) AS

OUTSTANDING_IDR,SUM(CKPNKOLE

KTIF_IDR) AS CKPNKOLEKTIF_IDR,

SUM(CKPNKOLEKTIF) AS

CKPNKOLEKTIF,


151



FACTCKPNCUST IMPAIRED_LOA

N_RATIO


as impaired_loan_ratio_per_branch

FROM FACTCKPNCUST

GROUP BY BRANCH_CODE) a

inner join dim_branch b

on a.branch_code = b.branch_code

group by b.main_branch_code

Condition:

FROM #tempCurrMonthCKPN

WHERE OUTSTANDING <> 0

GROUP BY DOWNLOAD_DATE, SEGMENT, CURRENCY, BRANCH_CODE,

PRODUCT_CODE, CUSTOMER_NUMBER,

PD_RATE, LGD_RATE, PD_RATE*LGD_RATE



BAB 5

IMPLEMENTASI OLAP

Setelah rancangan datamart PSAK 50/55 terbentuk, maka tahapan berikutnya

melakukan perancangan aplikasi pelaporan dan pemanfaatan tools analisa yang

akan digunakan oleh divisi keuangan, akuntansi dan manajemen risiko.

Melanjutkan dari perancangan dari datamart untuk pemenuhan penyusunan

pelaporan CKPN sesuai PSAK 50/55, kemudian akan dikembangkan untuk tools

analisa dengan pengolahan visualisasi Online Analytical Processing (OLAP).

Sebelum melakukan implementasi OLAP, diperlukan persiapan environment

server yang dapat menyediakan OLAP. Persiapan environment dalam penelitian

ini menggunakan databaseMicrosoft SQL Server 2012 dan IBM Cognos Insight

sebagai tools yang digunakan oleh pengguna dalam visualisasi laporan, grafik dan

analisa. Hasil pemrosesan ETL dan permodelan data dimensional (cube) akan

digunakan sebagai input dalam presentasi dan visualisasi laporan yang digunakan.

Dari kebutuhan 12 laporan yang telah dipaparkan pada fase analisa kebutuhan

informasi, sumber data yang digunakan dalam memfasilitasi ini dibedakan

menjadi 2 bagian yang terdiri dari informasi dari tabel fakta pembiayaan

(FACT_LOAN) dan berasal dari sumber tabel fakta CKPN (FACT_CKPN).

Termasuk didalamnya tabel-tabel dimensi yang berkaitan dengan masing-masing

tabel fakta.

5.1 Implementasi

Pada bab ini berisi tentang informasi yang disediakan oleh datamart PSAK.

Informasi tersebut digunakan untuk menghasilkan beberapa laporan yang nantinya

digunakan dalam pelaporan internal manajemen Bank X dan pelaporan eksternal

Bank X ke Bank Indonesia dan eksternal

Visualiasi OLAP yang telah dirancang dan dipresentasikan kepada pengguna

dengan menggunakan toolsIBM Cognos Insight. Presentasi tersebut akan


153


ditampilkan dalam bentuk masing-masing desktop dari pengguna selama

terhubung dengan databasedatamart PSAK melalui aplikasi cognos insight.

Sehingga pengguna dapat mengakses dimana saja baik secara online dan offline

yaitu dengan disimpan ke local device yang digunakan oleh pengguna, baik itu PC

ataupun mobile device.

5.1.1 Informasi Pembiayaan

Presentasi informasi pembiayaan akan menampilkan informasi portfolio

pembiyaan pada Bank X. Cube pembiayaan (CUBE_FACTLOAN) merupakan

hasil dari permodelan secara dimensional yang memungkinkan pengguna untuk

melakukan beberapa laporan terkait dengan pembiayaan yang dibutuhkan serta

melakukan analisa dengan berbagai persepektif dengan penggunaan fitur roll up,

drill down, dan slice and dice. Roll up dan drill down dapat dilakukan pada

dimensi branch, dimensi main branch dan dimensi area yang mana telah dilakukan

konfigurasi hirarki informasi dari tingkat hirarki tertinggi sampai dengan tingkat

granularitas yang paling kecil pada informasi pembiayaan per masing-masing

dimensi yang dipilih. Sedangkan slice and dice dapat dilakukan berdasarkan

kemungkinan dimensi yang ada yang terdiri dari :dimensi segmentasi dimensi

pembiayaan, dimensi kolektibilitas, dimensi currency, dimensi maturity profile,

dimensi pergerakan kolektibilitas, dimensi cabang, dimensi main branch, dimensi

area, dimensi akad dan dimensi periode waktu.

Sedangkan measurement untuk informasi pembiayaan berupa jumlah pembiayaan

itu sendiri, banyaknya pembiayaan, jumlah plafond, jumlah nonperfomingloan

dan rasio NPL. Struktur Cube informasi pembiayaaan dapat dilihat pada gambar

5.1


154


Gambar 5.1 Struktur Cube Informasi Pembiayaan

Beberapa gambar dibawah ini akan menjelaskan sampel dari presentasi OLAP

terkait dengan kebutuhan laporan yang terkait dengan informasi pembiyaan antara

lain; laporan total pembiayaan berdasarkan cabang, laporan pembiayaan

berdasarkan produk dan segment, laporan pembiayaan berdasarkan tanggal jatuh

tempo pembiayaan dan laporan pembiayaan mengalami perubahan kolektibilitas,

serta laporan ratio non perfoming loan (NPL).

Gambar 5.2 menjelaskan mengenai salah satu presentasi laporan Rasio Non

Performing Loan dari setiap cabang untuk beberapa periode di tahun 2014. Pada

laporan ini ditampilkan dengan cara diurutkan berdasarkan ratio NPL terbesar ke

rasio NPL terkecil.


155


Gambar 5.2 Presentasi Laporan rasio NPL per masing-masing cabang

Gambar 5.3 menjelaskan mengenai presentasi laporan pembiayaan berdasarkan

lamanya tempo pembiayaan per masing-masing periode termasuk visualisasi

grafik batang. Dimensi yang digunakan adalah dimensi maturity profile dan

dimensi waktu sedangkan yang menjadi measurementnya adalah Outstanding.


156


Gambar 5.3 Presentasi Laporan Pembiayaan berdasarkan lamanya jatuh

tempo

Gambar 5.4 menjelaskan mengenai presentasi laporan pembiayaan berdasarkan

pergerakan kolektibilitas dari periode januari 2014 ke periode februari 2014 untuk

semua cabang di Bank X. Dimensi yang digunakan adalah dimensi collectibility

movement field collectmovement_idpada posisi baris dan field flag

collectmovement pada posisi kolom, sedangkan dimensi waktu pada posisi kolom.

Measurement pada pelaporan ini adalah total pembiayaan per masing-masing

flagging pergerakan kolektibilitas. Flag 1 menunjukkan pembiayaan yang tidak

mengalami pergerakan kolektibilitas, Flag 2 menunjukkan pembiayaan yang

mengalami pergerakan kolektibilitas yang membaik, sedangkan Flag 3

menunjukkan pembiayaan yang mengalami pergerakan kolektibilitas yang

memburuk.Dari rangkuman pergerakan kolektibilitas dari laporan pada gambar

5.4, terdapat 6.44% mengalami pergerakan kolektibilitas yang memburuk yang

dapat dilihat pada Gambar 5.5


157


Gambar 5.4 Presentasi Laporan Pembiayaan berdasarkan pergerakan

kolektibilitas

Gambar 5.5 Presentasi summary Analisa Persentase pergerakan

kolektibilitas


158


5.1.2 Informasi Cadangan Kerugian Penurunan Nilai

Presentasi informasi CKPN akan menampilkan informasi CKPN untuk semua

portfolio pembiyaan pada Bank X. Cube CKPN (CUBE_CKPN) merupakan hasil

dari permodelan secara dimensional yang memungkinkan pengguna untuk

melakukan penyiapan beberapa laporan terkait dengan monitoring CKPN serta

melakukan analisa dengan berbagai persepektif dengan penggunaan fitur roll up,

drill down, dan slice and dice berdasarkan parameter dimensi yang dipilih sampai

dengan granularitas terendah pada level customer.

Laporan yang terkait dengan informasi CKPN terdiri dari Laporan Impairment

Ratio, Laporan Tren Probability Default(PD) dan Loss Given Default

(LGD),Laporan Collective Impairment berdasarkan group of impairment,Laporan

Impairment berdasarkan segmentasi,Laporan Variance CKPN Aktual dan CKPN

Forecast,Laporan Movement CKPN terbesar per cabang,Laporan top 10

Individual Impairment.

Gambar 5.6 merupakan struktur cube informasi CKPN yang terdiri dari satu

sumber tabel fakta dengan berbagai measurement yaitu PD Rate, LGD Rate,

Outstanding, PPAP, CKPN Forecast, CKPN Individual, CKPN Kolektif, Charged,

Released dan Impaired Loan Ratio. Sedangkan yang menjadi dimensinya terdiri

dari dimensi Impairment Group, Impairment Flag, Segment, Cabang, Currency,

Kolektibilitas, dan Periode waktu.


159


Gambar 5.6 Struktur Cube pada informasi CKPN

Gambar 5.7 merupakan salah satu presentasi Laporan monitoring CKPN Forecast,

CKPN Aktual, PPAP,dan Impaired Loan Ratio berdasarkan Area. Presentasi

laporan monitoring CKPN Forecast, CKPN Aktual, PPAP dan Impaired

LoanRatio dapat dilakukan drill down sesuai dengan hirarki dimensi yang dipilih

dari yang paling tinggi sampai dengan granularitas terkecil yaitu di level

customer. Berdasarkan nilai CKPN total terbesar di suatu area, kemudian di drill

down pada level cabang utama (main branch) yang tercermin pada gambar 5.8,

kemudian dari main branch di drill down ke level cabang yang tertera pada

gambar 5.9. Untuk mengetahui customer-customer mana saja yang memberikan

kontribusi CKPN terbesar di cabang tersebut maka dilkaukan drill down kembali

sampai dengan level granularitas terkecil, contoh kasus ini tertera pada gambar

5.10.

Demikian juga fitur roll up dari masing-masing nilai CKPN yang ada. Roll up

merupakan akumulasi dari nilai ckpn per masing-masing cabang sampai dengan

hirarki dimensi yang tertinggi. Penggunaan fasilitas drill down dan roll up ini

tergantung dari konfigurasi dimensi yang ada, dengan granularities dari level

branch, main branch sampai dengan area. Sedangkan granularitas terendah di


160


level customer number yang menjelaskan kontribusi CKPN untuk masing-masing

customer.

Gambar 5.7 menggambarkan analisa total CKPN berdasarkan area. Analisa yang

dapat diperoleh adalah Rasio Impairment loan yangpaling besar dan nilai

CKPNnya paling besar terdapat di bulan februari 2014, Area TIER-ONE CITY 1.

Gambar 5.7 Presentasi Laporan monitoring CKPN Forecast, CKPN Aktual,

PPAP,dan Impaired Loan Ratio berdasarkan cabang, main branch dan area

Gambar 5.8 merupakan hasil drill down dari area ke main branch, didapatkan

bahwa cabang utama (main_branch) kalimalang dengan kode cabang 305

memberikan kontribusi pembentukan nilai CKPN terbesar.


161


Gambar 5. 8 Presentasi Drill down dari Area ke Main Branch untuk

Laporan monitoring CKPN Forecast, CKPN Aktual, PPAP,dan Impaired

Loan Ratio berdasarkan cabang, main branch dan area

Gambar 5.9 adalah bentuk dari drill down dari cabang utama ke cabang.Cabang

Kalimalang merupakan kontribusi terbesar. Maka untuk mengetahui daftar dari

customer-customer mana saja yang memberikan kontribusi CKPN terbesar

terdapat pada gambar 5.10.


162


Gambar 5. 9 Presentasi Drill down dari Main Branch ke Branch dengan

CKPN Total terbesar di periode Februari 2014.


163


Gambar 5. 10 Presentasi Drill down dari Branch ke daftar customer dengan

CKPN Total terbesar di periode Februari 2014.

Gambar 5.11 menjelaskan mengenai presentasi laporan tren PD dan LGD mulai

dari periode Februari, Maret dan April 2014. Dimensi yang digunakan dalam

pembuatan laporan ini adalah Dimensi Collective Impairment Group dan Dimensi

waktu, sedangkan measurementnya adalah PD Rate, LGD Rate dan Expected Loss

Rate.

Gambar 5.11 Presentasi laporan PD dan LGD Trend

Gambar 5.12 menjelaskan mengenai presentasi laporan perbandingan antara

PPAP dan CKPN Aktual. Dimensi yang digunakan dalam pembuatan laporan ini

adalah Dimensi Collective Impairment Group dan Dimensi waktu, sedangkan

measurementnya adalah PPAP, CKPN dan komputasi sederhana yaitu PPAP

dikurangi dengan CKPN.


164


Gambar 5. 12 Presentasi laporan perbandingan PPAP dengan CKPN

Beberapa laporan yang terkait kepada informasi CKPN lainnya terlihat

pada Gambar 5.13, Gambar 5.14 dan Gambar 5.15

Gambar 5. 13 Presentasi laporan Movement CKPN Charged terbesar

dikelompokkan berdasarkan cabang pada periode April 2014


165


Gambar 5.14 Presentasi laporan Movement CKPN Released terbesar

dikelompokkan berdasarkan cabang pada periode April 2014

Gambar 5. 15 Presentasi laporan collective Impairment berdasarkan group

of Impairment


166


Gambar 5.16 Presentasi laporan collective Impairment berdasarkan

Segmentasi Pembiayaan pada bulan April 2014

Penggunaan berbagai fitur analisa pada OLAP seperti drill down, drill up dan

slice and dice, what if analysis, membuat tambahan komputasi baru dari informasi

yang tersedia misalnya variance antara nilai CKPN Aktual dan CKPN forcast,

variance antara nilai pencadangan yang berdasarkan formula PPAP dan formula

CKPN secara dinamis dengan click and drag secara on the fly tanpa

ketergantungan dengan tim IT dalam menyediakan pelaporan yang diminta.

Fitur lainnya adalah pengguna dapat mengganti data view secara on the fly, dalam

aktivitas sorting, pencarian data tertentu dapat digunakan untuk melakukan

berbagai macam analisa sesuai dengan kebutuhan dari pengguna. Pengguna dapat

melakukan pengaturan slice and dice tergantung dari dimensi dan measurement

yang terdapat dari masing-masing report. Salah satu contoh dalam penelitian ini

terletak laporan variance nilai CKPN actual dan CKPN forecast.

Manfaat lain yang didapat dari penggunaan OLAP adalah representasi visualisasi

dalam bentuk grafik dimana secara dinamis. Dashboard berupa pie chart untuk

komposisi CKPN per masing-masing cabang. Informasi dalam bentuk grafik

sudah dalam bentuk dinamis, grafik akan berubah tergantung dari parameter dan

data yang ada pada cross tab report. Visualisasi yang dinamis juga dapat

merepresentasikan fasilitas drill down dari informasi yang dipilih. Ketika bulan


167


periode pelaporan diganti maka pie chart dari masing-masing measurementyang

ditampilkan (CKPN total) akan berubah dengan menampilkan data untuk bulan

pelaporan tersebut.

5.2 Uji Coba

Setelah semua laporan yang dibutuhkan oleh pengguna diimplementasikan

melalui OLAP, maka aktivitas selanjutnya adalah melakukan uji coba acceptance

oleh masing-masing pengguna akhir apakah setiap laporan yang dibuat sesuai

dengan ekspektasi kebutuhan pengguna baik dari aspek lamanya pemrosesan,

kebutuhan informasi dan keakuratan data.

Setelah dilakukan uji coba selama tiga kali periode pelaporan, pemrosesan pada

penelitian ini memerlukan waktu kurang lebih selama rata-rata +/- 51 menit, mulai

dari ekstraksi data staging, transformasi data staging, transformasi ke dalam

bentuk dimensional modeling sampai dengan pemrosesan cube menampilkan

dalam bentuk masing-masing laporan yang diperlukan oleh pengguna. Waktu

pemrosesan dihitung ketika semua sumber data siap untuk digunakan dan tidak

termasuk waktu untuk melakukan analisa oleh masing-masing pengguna. Tabel

5.1 merupakan contoh dari pemrosesan datamart informasi CKPN pada periode

januari sampai dengan periode maret 2014.


168


Tabel 5.1 Tabel pemrosesan informasi CKPN pada periode Januari – Maret

2014

Adapun berbagai skenario dalam melakukan uji coba acceptance hasil

implementasi datamart dan OLAP pada penelitian ini, antara lain:

1. Membandingkan total data pembiayaan dari datamart dengan laporan neraca

Bank X periode tertentu. (Lampiran 7)

2. Membandingkan laporan Probability Default untuk masing-masing

metodologi Net Flow Rate dan Migration Analysis dengan cara menghitung

ulang secara manual nilai Probability Default untuk masing-masing metode

dan segmentasi impairment group. (Lampiran 8)

3. Membandingkan laporan Loss Given Defaultuntuk masing-masing metodologi

Expected Recoveries dan Collateral Shortfall dengan caramelakukan

perhitungan ulang secara manual. (Lampiran 9)

4. Membandingkan laporan perhitungan CKPN kolektif per masing-masing

impairment group dan kolektibilitas dengan mengalikan komponen persentase

dari PD, persentase LGD dan nilai Pembiayaan dalam mata uang Rupiah per

masing-masing kolektibilitas. (Lampiran 10)

Persetujuan dari hasil uji coba ini diakhiri dengan tanda tangan dari masing-

masing pengguna yang terlibat dalam mempersiapkan laporan ini. (Lampiran 11)



BAB 6

KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan dan saran dari penelitian yang telah dilakukan mengenai

penerapan datamart PSAK dan OLAP pada Bank X dalam rangka penyusunan

dan monitoring laporan CKPN sesuai dengan PSAK 50/55.

6.1 Kesimpulan

Dari hasil penelitian terhadap rancangan datamart PSAK dan penerapan OLAP

untuk mendukung proses pembuatan dan monitoring laporan pembiayaan dan

CKPN dapat disampaikan beberapa kesimpulan sebagai berikut:

1. Subjek data yang dibutuhkan pada pengembangan datamart PSAK untuk

penyusunan laporan dan monitoring CKPN adalah data pembiayaan, data

histori pembiayaan selama 3 tahun terakhir, data customer, dan data manual

yang terdiri dari data parameter kebijakan perhitungan CKPN, dan data yang

tidak terdapat pada core banking systems Bank. Contohnya: data target

penyisihan CKPN, data hapus buku, data recovery, data manual adjustment.

2. Data preparation untuk menghasilkan perhitungan CKPN pada proses ETL

merupakan fase yang paling penting, mengingat serangkaian langkah-langkah

pemrosesan yang harus dijalankan mengikuti alur bisnis proses perhitungan

CKPN sesuai dengan PSAK 50/55.

3. Perancangan data mart PSAK terhadap data pembiayaan dan penyisihan

CKPN pada Bank X menghasilkan 14 tabel dimensi yaitu: dimensi periode,

dimensi akad, dimensi currency, dimensi cabang, dimensi main branch,

dimensi area, dimensi segmentasi, dimensi collective group, dimensi produk,

dimensi kolektibilitas, dimensi movement kolektibilitas, dimensi maturity

profile, dimensi impairment flag dan dimensi customer. Dan dua tabel fakta,

yaitu: fakta pembiayaan, dan fakta CKPN. Skema perancangan menggunakan

star schema untuk masing-masing tabel fakta dengan tujuan untuk

optimalisasi proses query.


170


4. Implementasi datamart dengan otomasi proses perhitungan dan penyusunan

pelaporan per periode setiap akhir bulan hanya memerlukan waktu proses

selama +/- 50-60 menit. Proses tersebut sudah termasuk ekstraksi,

transformasi data staging dalam perhitungan CKPN, transformasi data dimensi

dan load data pada tabel fakta dengan menggunakan scheduler pada utilitas

ETL. Apabila tidak tersedia datamart dan tidak ada otomasi proses

perhitungan CKPN, penyusunan laporan membutuhkan 5 hari kerja. Itupun

data yang digunakan sebulan sebelumnya, bukan data pada posisi bulan

pelaporan.

5. Dengan penerapan arsitektur independent data mart, implementasi dapat

dilakukan dengan lebih cepat, selain itu dapat dengan mudah dilakukan

pengulangan proses batch ETL secara end to end mulai dari proses ekstraksi

sumber data sampai load ke datamart PSAK setiap periode pelaporan tanpa

menunggu kesiapan data pada enterprise data warehouse perusahaan. Manfaat

lain yang diperoleh adalah fleksibilitas terhadap adjustment, mengingat nature

dari proses bisnis sistem pelaporan yang selalu memerlukan adjustment secara

manual. Data adjustment menjadi subyek input data pada datamart PSAK

yang terpisah dari original data yang berasal dari database operasional.

6. Dengan pemanfaatan OLAP, maka ketidaktergantungan terhadap IT

merupakan manfaat tersendiri bagi pengguna, terutama dalam pemrosesan

data dan query data sesuai dengan masing-masing kebutuhan informasi.

Pengguna dapat melakukan self service disesuaikan dengan berbagai analisa

perspektif oleh masing-masing pengguna.

6.2 Saran

Berdasarkan penelitian ini, dapat disampaikan beberapa saran untuk digunakan

pada penelitian selanjutnya.

1. Dengan model datamart yang ada ini dapat dilakukan pengembangan lebih

lanjut dengan melakukan penerapan data mining yang digunakan untuk

prediksi probabilitas dari debitur yang akan mengalami gagal bayar sehingga

dapat digunakan untuk keperluan forecasting.


171


2. Hasil implementasi datamart dan OLAP ini dapat dikembangkan ke model

business intelligence menggunakan dashboard dengan memasukkan berbagai

kinerja pengukuran lainnya yang menjadi indikator kinerja bank, seperti Non

Perfoming Loan, Rasio Loan Impairment, Capital Adequacy Ratio, Loan to

Value Ratio, Loan/Earning Assets, Net Interest Margin dan Rasio Cost

Efficiency.

3. Pengembangan data model yang mendukung seluruh penerapan regulatory

compliance di Bank X yang sanggup memberikan solusi terhadap berbagai

pelaporan perbankan di Indonesia dengan single view of the truth, mencakup

laporan Laporan Bank Umum (LBU) Basel II, Laporan Harian Bank Umum

(LHBU), Laporan Berkala Bank Umum (LBBU), Laporan Kantor Pusat Bank

Umum (LKPBU), Legal Lending Limit (LLL), Lalu Lintas Devisa (LLD),

Risk Weighted Asset (RWA), dan Sitem Informasi Debitur (SID).

4. Penelitian selanjutnya terkait dengan optimalisasi performance physical

storage di database yaitu dengan membuat pemisahan partition sesuai dengan

kebutuhan. Pemisahan partition terdiri dari repository partition yang

digunakan untuk menyimpan raw data atau unnormalized data yang berasal

dari berbagai sumber, kemudian Datamart partition yang hanya terdiri dari

permodelan dimensional yang sudah dilakukan normalisasi, serta archiving

partition untuk menyimpan data histori berdasarkan masing-masing periode

dari kebijakan data archiving.



DAFTAR PUSTAKA

Angreine Kewo (2013), OLAP Best Solution for Multidimensional Grocery Business Model :International Conference of Information and Communication Technology (ICoICT). Ariyachandra dan Hugh J. Watson, Which Data Warehouse Architecture Is Most Successful?Business Intelligence Journal Volume 11. Connolly, T., & Begg, C. (2005).Database System: A Practical Approach to Design, Implementation and Management (4 th ed).England: Addison Wesley. Efraim Turban, Ramesh Sharda, Dursun Delen (2011). Decision Support and Business Intelligence Systems.(9th edition).America : Pearson Education, Inc. Han J & Kamber M. (2006).Data Mining Concept & Techniques. Simon Fraser University. USA : Morgan Kaufman Hasan & Hyland (2001):Using OLAP and Multidimensional Data for Decision Making : IEEE Journal Indra. (2011). Perancangan serta Penerapan Data Warehouse dan Business Intelligence untuk Evaluasi Program Studi Berdasarkan Evaluasi Diri (EPSBED): Studi Kasus Universitas Budi Luhur. Jakarta: Universitas Indonesia. Inmon, W.H. (2005). Building The Data Warehouse. 4thEdition, John Wiley & Sons,Inc., New York.

Kimbal, R.,& Ross, M. (2002). The Data Warehouse Toolkit The Complete Guide to Dimensional Modeling.(2nd edition). Canada: John Wiley and Sons.

Mary Breslin, (2004) :Data Warehousing Battle of the Giants : Comparing the Basics of the Kimball and Inmon Models, Business Intelligence Journal, Winter 2004. Nitin Anand, Manoj Kumar (2013):Modeling and Optimization of Extraction-Transformation Loading (ETL) processes in Data Warehouse: An Overview. India :4th ICCCNT 2013 July 4-6, 2013 Tiruchengode Per Bertilsson, Johan Frisell, Carl-Johan Sylvan (2009). Information Quality Realization in Business Intelligence Systems, Lund University Publications Ralph Kimball (2008). Slowly Changing Dimensions, Part 2. Kimball Group. January 20, 2013 from http://www.kimballgroup.com/2008/09/22/slowly-changing-dimensions-part-2/print/


173


Sandip Singh& Sona Malhotra, (2011) :Datawarehouse and its method , Journal of Global Research in Computer Science, Volume 2 No (5), May 2011 Surat Edaran Bank Indonesia Nomor 11/4/DPNP tanggal 27 Januari 2009 perihal Pelaksanaan Pedoman Akuntansi Perbankan Indonesia Surat Edaran Bank Indonesia Nomor 15/26/DPbS perihal Pelaksanaan Pedoman Akuntansi Perbankan Syariah Indonesia Tim Penyusun (2008), Pedoman Akuntansi Perbankan Indonesia (PAPI) : Bank Indonesia Tim Penyusun (2014), Pedoman Akuntansi Perbankan Syariah Indonesia (PAPSI) : Bank Indonesia Vangipuram Radhakrishna, Vangipuram SravanKiran, K. Ravikiran, (2012) :Automating ETL Process with Scripting Technology, 2012 Nirma University International Conference on Engineering, Nuicone-2012, 06-08 December 2012. Yao, Kan (2003).Design issues in data warehousing : a case study. Masters thesis, Concordia University.


174


DAFTAR LAMPIRAN

Lampiran 1 : Hasil meeting mengenai analisa kebutuhan informasi

segmentasi Impairment

Lampiran 2 : Ektraksi dari sumber data


175


Lampiran 3 : Script ETL data preprocessing -- -- SP_PSAK_CALC_LGD (Procedure) -- CREATEORREPLACEPROCEDUREPSAKUATA.SP_PSAK_CALC_LGDAS V_CURRMONTHDATE; V_PREVMONTHDATE; BEGIN BEGIN SELECTCURRDATE,LAST_DAY(ADD_MONTHS(CURRDATE,-1)) INTOV_CURRMONTH,V_PREVMONTH FROMPSAK_PRC_DATE; EXCEPTION WHENNO_DATA_FOUNDTHEN NULL; END; --V_CURRMONTH := TO_DATE('20131231','YYYYMMDD'); --V_PREVMONTH := TO_DATE('20131130','YYYYMMDD'); --**EXPECTED RECOVERY**-- DELETEPSAK_LGD_EXPECTED_RECOVERYERWHEREER.PERIOD=V_CURRMONTH; COMMIT; INSERTINTOPSAK_LGD_EXPECTED_RECOVERY (PERIOD, LGD_SEGMENT, WO_AMOUNT, RECOVERY_AMOUNT, AYDA_AMOUNT, LGL_RATIO, LGD_RATIO) SELECTLAST_DAY(TO_DATE(ER.PERIODE,'YYYYMM'))ASPERIOD, SG.COLLECTIVE_GROUP_2,--ER.SEGMENT, ER.WO, ER.RECOVERY, ER.AYDA, (ER.WO+ER.AYDA)/(ER.AYDA+ER.RECOVERY)ASLGL_RATIO, 1 -((ER.WO+ER.AYDA)/(ER.AYDA+ER.RECOVERY))ASLGD_RATIO FROMPSAK_EXPECTED_RECOV_UPLOADER INNERJOINPSAK_BMI_SEGMENTSG ONER.SEGMENT=SG.C09_SEGMENTASI_ACCOUNT WHEREER.PERIODE=TO_CHAR(V_CURRMONTH,'YYYYMM'); COMMIT; MERGEINTOPSAK_LGD_EXPECTED_RECOVERYER USING (SELECTA.LGD_SEGMENT,AVG(A.LGL_RATIO)ASLGD_RATIO FROMPSAK_LGD_EXPECTED_RECOVERYA INNERJOINPSAK_LGD_SETTINGB ONA.LGD_SEGMENT=B.LGD_SEGMENT WHEREA.PERIODBETWEEN ADD_MONTHS(V_CURRMONTH,B.HISTORICAL_DATA*-1)AND V_CURRMONTH GROUPBYA.LGD_SEGMENT)ER_AVG


176


ON (ER.LGD_SEGMENT=ER_AVG.LGD_SEGMENTANDER.PERIOD=V_CURRMONTH) WHENMATCHEDTHEN UPDATESETER.LGD_RATIO=ER_AVG.LGD_RATIO; COMMIT; INSERTINTOPSAK_RECOVERY_MATRIX (PRODUCT_GROUP, PERIOD, WO_OUTSTANDING, RECOVERY_AMOUNT, RECOVERY_RATE, AVERAGE_RATE, LIP) SELECTER.LGD_SEGMENT, TO_CHAR(ER.PERIOD,'YYYYMM'), 0, 0, ER.LGD_RATIO, 0, 1 FROMPSAK_LGD_EXPECTED_RECOVERYER WHEREER.PERIOD=V_CURRMONTH; COMMIT; --**COLLATERAL SHOSTFALL**-- DELETEPSAK_LGD_COLLATERAL_SHORTFALLSFWHERESF.PERIOD=V_CURRMONTH; COMMIT; INSERTINTOPSAK_LGD_COLLATERAL_SHORTFALL (PERIOD, LGD_SEGMENT, OUTSTANDING, COLLATERAL_AMOUNT, LGL_RATIO, LGD_RATIO) SELECTLAST_DAY(TO_DATE(SF.PERIODE,'YYYYMM'))ASPERIOD, SG.C09_SEGMENTASI_ACCOUNT,--SF.SEGMENT, SF.OUTSTANDING, SF.AGUNAN, (SF.OUTSTANDING-SF.AGUNAN)/SF.OUTSTANDINGASLGL_RATIO, (SF.OUTSTANDING-SF.AGUNAN)/SF.OUTSTANDINGASLGD_RATIO FROMPSAK_COLL_SHORTFALL_UPLOADSF INNERJOINPSAK_BMI_SEGMENTSG ONSF.SEGMENT=SG.C09_SEGMENTASI_ACCOUNT WHERESF.PERIODE=TO_CHAR(V_CURRMONTH,'YYYYMM') AND(SF.OUTSTANDING-SF.AGUNAN)> 0; COMMIT; MERGEINTOPSAK_LGD_COLLATERAL_SHORTFALLER USING (SELECTA.LGD_SEGMENT,AVG(A.LGL_RATIO)ASLGD_RATIO FROMPSAK_LGD_COLLATERAL_SHORTFALLA INNERJOINPSAK_LGD_SETTINGB ONA.LGD_SEGMENT=B.LGD_SEGMENT WHEREA.PERIODBETWEEN ADD_MONTHS(V_CURRMONTH,B.HISTORICAL_DATA*-1)AND V_CURRMONTH GROUPBYA.LGD_SEGMENT)ER_AVG


177


ON (ER.LGD_SEGMENT=ER_AVG.LGD_SEGMENTANDER.PERIOD=V_CURRMONTH) WHENMATCHEDTHEN UPDATESETER.LGD_RATIO=ER_AVG.LGD_RATIO; COMMIT; INSERTINTOPSAK_RECOVERY_MATRIX (PRODUCT_GROUP, PERIOD, WO_OUTSTANDING, RECOVERY_AMOUNT, RECOVERY_RATE, AVERAGE_RATE, LIP) SELECTSF.LGD_SEGMENT, TO_CHAR(SF.PERIOD,'YYYYMM'), 0, 0, 1 -SF.LGD_RATIO, 0, 1 FROMPSAK_LGD_COLLATERAL_SHORTFALLSF WHERESF.PERIOD=V_CURRMONTH; COMMIT; END; / Lampiran 4 : Script ETL data loading ke masing-masing tabel Fakta --- STEP 01 CREATE TEMPORARY TABLE CURRENT AND PREVIOUS droptable#tempPrevMonthCKPN droptable#tempCurrMonthCKPN select DOWNLOAD_DATE, SEGMENT, PRODUCT_GROUP, currency, branch_code, product_code, CUSTOMER_NUMBER, account_number, bi_collectability, EXCHANGE_RATE, outstanding, plafond, COLLATERAL_VALUE_FOR_IMPAIR, PD_RATE, LGD_RATE, PIP_AMOUNT, IIP_AMOUNT, UNWINDING_AMOUNT, BEGINNING_BALANCE, CHARGE, WRITEBACK, ENDING_BALANCE, IS_IMPAIRED,


178


impaired_flag, 'Y'ASFLAG_CURRENT into#tempCurrMonthCKPN frompsak_master_account WHEREDOWNLOAD_DATE='2014-01-31' select DOWNLOAD_DATE, SEGMENT, PRODUCT_GROUP, currency, branch_code, product_code, CUSTOMER_NUMBER, account_number, bi_collectability, EXCHANGE_RATE, outstanding, plafond, COLLATERAL_VALUE_FOR_IMPAIR, PD_RATE, LGD_RATE, PIP_AMOUNT, IIP_AMOUNT, UNWINDING_AMOUNT, BEGINNING_BALANCE, CHARGE, WRITEBACK, ENDING_BALANCE, IS_IMPAIRED, impaired_flag, 'N'ASFLAG_CURRENT into#tempPrevMonthCKPN frompsak_master_account WHEREDOWNLOAD_DATE='2014-12-31' -- STEP #2 INSERT INTO FACTCKPNCUST -- 2A PREV ADA CURRENT ADA INSERTINTOFACTCKPNCUST ( DOWNLOAD_DATE, SEGMENT, COLLECTIVE_GROUP, CURRENCY, BRANCH_CODE, PRODUCT_CODE, CUSTOMER_NUMBER, KOL_MOV, PD_RATE, LGD_RATE, EXPECTED_LOSS_RATE, MAX_BIKOL, OUTSTANDING, OUTSTANDING_IDR, PLAFOND, PLAFOND_IDR, COLLATERAL_VALUE, COLLATERALVALUE_IDR, CKPNKOLEKTIF, CKPNKOLEKTIF_IDR,


179


CKPNINDIVIDUAL, CKPNINDIVIDUAL_IDR, UNWINDING_AMOUNT, UNWINDING_IDR, CHARGE, CHARGE_IDR, WRITEBACK, WRITEBACK_IDR, CKPNFORECAST, CKPNFORECAST_IDR, PPAP, IMPAIRED_LOAN_RATIO, IA_CA_FLAG, FLAG_CURRENT ) SELECT A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE, A.PRODUCT_CODE, A.CUSTOMER_NUMBER, CASE WHENCONVERT(varchar(1),MAX(B.bi_collectability))ISNULL THENCONVERT(varchar(1),MAX(A.bi_collectability))+'-'+CONVERT(varchar(1),MAX(A.bi_collectability)) ELSE CONVERT(varchar(1),MAX(B.bi_collectability))+'-'+CONVERT(varchar(1),MAX(A.bi_collectability)) ENDASKOL_MOV, --FLAG_CURRENT, A.PD_RATE, A.LGD_RATE, A.PD_RATE*A.LGD_RATE, MAX(A.BI_COLLECTABILITY)ASMAX_BIKOL, SUM(ISNULL(A.OUTSTANDING,0)), SUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PLAFOND,0)), SUM(ISNULL(A.PLAFOND,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PIP_AMOUNT,0)), SUM(ISNULL(A.PIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.IIP_AMOUNT,0)), SUM(ISNULL(A.IIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.CHARGE,0)), SUM(ISNULL(A.CHARGE,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.WRITEBACK,0)), SUM(ISNULL(A.WRITEBACK,0)*ISNULL(A.EXCHANGE_RATE,1))ASWRITEBACK_IDR, 0 ASCKPNFORECAST, 0 ASCKPNFORECAST_IDR, CASE WHENMAX(A.BI_COLLECTABILITY)=1 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.01) WHENMAX(A.BI_COLLECTABILITY)=2 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.05)


180


WHENMAX(A.BI_COLLECTABILITY)=3 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.15) WHENMAX(A.BI_COLLECTABILITY)=4 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.50) WHENMAX(A.BI_COLLECTABILITY)=5 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 1) ELSE 0 ENDASPPAP, 0, A.IMPAIRED_FLAG, 'N' FROM#tempCurrMonthCKPNA INNERJOIN#tempCurrMonthCKPNB ONA.ACCOUNT_NUMBER=B.ACCOUNT_NUMBER GROUPBY A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE, A.PRODUCT_CODE, A.CUSTOMER_NUMBER, A.PD_RATE, A.LGD_RATE, A.IMPAIRED_FLAG -- 2B PREV ADA CURRENT TIDAK ADA INSERTINTOFACTCKPNCUST ( DOWNLOAD_DATE, SEGMENT, COLLECTIVE_GROUP, CURRENCY, BRANCH_CODE, PRODUCT_CODE, CUSTOMER_NUMBER, KOL_MOV, PD_RATE, LGD_RATE, EXPECTED_LOSS_RATE, MAX_BIKOL, OUTSTANDING, OUTSTANDING_IDR, PLAFOND, PLAFOND_IDR, COLLATERAL_VALUE, COLLATERALVALUE_IDR, CKPNKOLEKTIF, CKPNKOLEKTIF_IDR, CKPNINDIVIDUAL, CKPNINDIVIDUAL_IDR, UNWINDING_AMOUNT, UNWINDING_IDR, CHARGE, CHARGE_IDR, WRITEBACK, WRITEBACK_IDR, CKPNFORECAST, CKPNFORECAST_IDR, PPAP,


181


IMPAIRED_LOAN_RATIO, IA_CA_FLAG, FLAG_CURRENT ) SELECT A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE, A.PRODUCT_CODE, A.CUSTOMER_NUMBER, CONVERT(varchar(1),MAX(a.bi_collectability))+'-'+'0'ASKOL_MOV, --FLAG_CURRENT, A.PD_RATE, A.LGD_RATE, A.PD_RATE*A.LGD_RATE, MAX(A.BI_COLLECTABILITY)ASMAX_BIKOL, SUM(ISNULL(A.OUTSTANDING,0)), SUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PLAFOND,0)), SUM(ISNULL(A.PLAFOND,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PIP_AMOUNT,0)), SUM(ISNULL(A.PIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.IIP_AMOUNT,0)), SUM(ISNULL(A.IIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.CHARGE,0)), SUM(ISNULL(A.CHARGE,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.WRITEBACK,0)), SUM(ISNULL(A.WRITEBACK,0)*ISNULL(A.EXCHANGE_RATE,1))ASWRITEBACK_IDR, 0 ASCKPNFORECAST, 0 ASCKPNFORECAST_IDR, CASE WHENMAX(A.BI_COLLECTABILITY)=1 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.01) WHENMAX(A.BI_COLLECTABILITY)=2 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.05) WHENMAX(A.BI_COLLECTABILITY)=3 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.15) WHENMAX(A.BI_COLLECTABILITY)=4 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.50) WHENMAX(A.BI_COLLECTABILITY)=5 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 1) ELSE 0 ENDASPPAP, 0, A.IMPAIRED_FLAG, 'N' FROM#tempPrevMonthCKPNA WHEREa.ACCOUNT_NUMBERNOTIN(SELECTACCOUNT_NUMBERFROM#tempCurrMonthCKPN) GROUPBY A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE,


182


A.PRODUCT_CODE, A.CUSTOMER_NUMBER, A.PD_RATE, A.LGD_RATE, A.IMPAIRED_FLAG --2C : INSERT KE PREV TIDAK ADA CURRENT ADA --> NEW ACCOUNT INSERTINTOFACTCKPNCUST ( DOWNLOAD_DATE, SEGMENT, COLLECTIVE_GROUP, CURRENCY, BRANCH_CODE, PRODUCT_CODE, CUSTOMER_NUMBER, KOL_MOV, PD_RATE, LGD_RATE, EXPECTED_LOSS_RATE, MAX_BIKOL, OUTSTANDING, OUTSTANDING_IDR, PLAFOND, PLAFOND_IDR, COLLATERAL_VALUE, COLLATERALVALUE_IDR, CKPNKOLEKTIF, CKPNKOLEKTIF_IDR, CKPNINDIVIDUAL, CKPNINDIVIDUAL_IDR, UNWINDING_AMOUNT, UNWINDING_IDR, CHARGE, CHARGE_IDR, WRITEBACK, WRITEBACK_IDR, CKPNFORECAST, CKPNFORECAST_IDR, PPAP, IMPAIRED_LOAN_RATIO, IA_CA_FLAG, FLAG_CURRENT ) SELECT A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE, A.PRODUCT_CODE, A.CUSTOMER_NUMBER, CONVERT(varchar(1),MAX(a.bi_collectability))+'-'+CONVERT(varchar(1),MAX(a.bi_collectability))asKOL_MOV, --FLAG_CURRENT, A.PD_RATE, A.LGD_RATE, A.PD_RATE*A.LGD_RATE, MAX(A.BI_COLLECTABILITY)ASMAX_BIKOL,


183


SUM(ISNULL(A.OUTSTANDING,0)), SUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PLAFOND,0)), SUM(ISNULL(A.PLAFOND,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)), SUM(ISNULL(A.COLLATERAL_VALUE_FOR_IMPAIR,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.PIP_AMOUNT,0)), SUM(ISNULL(A.PIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.IIP_AMOUNT,0)), SUM(ISNULL(A.IIP_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)), SUM(ISNULL(A.UNWINDING_AMOUNT,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.CHARGE,0)), SUM(ISNULL(A.CHARGE,0)*ISNULL(A.EXCHANGE_RATE,1)), SUM(ISNULL(A.WRITEBACK,0)), SUM(ISNULL(A.WRITEBACK,0)*ISNULL(A.EXCHANGE_RATE,1))ASWRITEBACK_IDR, 0 ASCKPNFORECAST, 0 ASCKPNFORECAST_IDR, CASE WHENMAX(A.BI_COLLECTABILITY)=1 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.01) WHENMAX(A.BI_COLLECTABILITY)=2 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.05) WHENMAX(A.BI_COLLECTABILITY)=3 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.15) WHENMAX(A.BI_COLLECTABILITY)=4 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 0.50) WHENMAX(A.BI_COLLECTABILITY)=5 THENSUM(ISNULL(A.OUTSTANDING,0)*ISNULL(A.EXCHANGE_RATE,1)* 1) ELSE 0 ENDASPPAP, 0, A.IMPAIRED_FLAG, 'Y' FROM#tempCurrMonthCKPNA WHEREa.ACCOUNT_NUMBERNOTIN(SELECTACCOUNT_NUMBERFROM#tempPrevMonthCKPN) GROUPBY A.DOWNLOAD_DATE, A.SEGMENT, A.PRODUCT_GROUP, A.CURRENCY, A.BRANCH_CODE, A.PRODUCT_CODE, A.CUSTOMER_NUMBER, A.PD_RATE, A.LGD_RATE, A.IMPAIRED_FLAG --- STEP 3 --- UPDATE CKPNFORECAST_IDR DI TABLE FACTCKPNCUST --- UPDATEFACTCKPNCUST SET CKPNFORECAST_IDR=A.OUTSTANDING_IDR/Y.SUMOUTS_BRANCH*X.CKPN_TARGET_BRANCH --,IMPAIRED_LOAN_RATIO=CASE WHEN OUTSTANDING<>0 THEN (A.CKPNKOLEKTIF_IDR+A.CKPNINDIVIDUAL_IDR)/A.OUTSTANDING_IDR -- ELSE 0 --END FROMFACTCKPNCUSTA INNERJOINPSAK_CKPN_TARGET_BRANCHX


184


ONA.DOWNLOAD_DATE=X.DOWNLOAD_DATEANDA.BRANCH_CODE=X.BRANCH_CODE INNERJOIN(SELECTDOWNLOAD_DATE,BRANCH_CODE,SUM(OUTSTANDING_IDR)ASSUMOUTS_BRANCHFROMPSAK_CKPN_TARGET_BRANCHGROUPBYDOWNLOAD_dATE,BRANCH_CODE)Y ONA.DOWNLOAD_DATE=Y.DOWNLOAD_DATEANDA.BRANCH_CODE=Y.BRANCH_CODE WHEREA.DOWNLOAD_DATE='20140131' --- UPDATE FACTCKPNCUST IMPAIRED_LOAN_RATIO --- UPDATEFACTCKPNCUST SETIMPAIRED_LOAN_RATIO=X.IMPAIRED_LOAN_RATIO_PER_BRANCH FROMFACTCKPNCUSTA INNERJOINPSAK_CKPN_TARGET_BRANCHX ONA.DOWNLOAD_DATE=X.DOWNLOAD_DATEANDA.BRANCH_CODE=X.BRANCH_CODE INNERJOIN(SELECTDOWNLOAD_DATE,BRANCH_CODE,SUM(OUTSTANDING_IDR)ASSUMOUTS_BRANCHFROMPSAK_CKPN_TARGET_BRANCHGROUPBYDOWNLOAD_dATE,BRANCH_CODE)Y ONA.DOWNLOAD_DATE=Y.DOWNLOAD_DATEANDA.BRANCH_CODE=Y.BRANCH_CODE WHEREA.DOWNLOAD_DATE='20140131' --- INSERT INTO FACT_CKPN INSERTINTOFACT_CKPN ( DOWNLOAD_DATE, AKAD_CODE, SEGMENT_SK, CURRENCY, AREA_CODE, MAIN_BRANCH_CODE, BRANCH_CODE, CUSTOMER_NUMBER, PRODUCT_CODE, IMPAIRMENTGROUP_CODE, PD_RATE, LGD_RATE, EXPECTED_LOSS_RATE, FLAG_IMPAIRED, COLLECTMOVEMENT_SK, MAX_BICOLLECTABILITY, OUTSTANDING, PLAFOND, COLLATERAL_VALUE, PPAP, CKPNFORECAST, CKPNINDIVIDUAL, CKPNKOLEKTIF, CKPNTOTAL, CHARGED, RELEASED, IMPAIRED_LOAN_RATIO ) SELECT A.DOWNLOAD_DATE, 'A', ISNULL(C.SEGMENT_SK,'999'), A.CURRENCY, B.AREA_CODE, B.MAIN_BRANCH_CODE, A.BRANCH_CODE, A.CUSTOMER_NUMBER, A.PRODUCT_CODE, E.IMPAIRMENTGROUP_CODE,


185


A.PD_RATE, A.LGD_RATE, A.EXPECTED_LOSS_RATE, A.IA_CA_FLAG, D.COLLECTMOVEMENT_SK, A.MAX_BIKOL, A.OUTSTANDING_IDR, A.PLAFOND_IDR, A.COLLATERALVALUE_IDR, A.PPAP, A.CKPNFORECAST_IDR, A.CKPNINDIVIDUAL_IDR, A.CKPNKOLEKTIF_IDR, A.CKPNINDIVIDUAL_IDR+CKPNKOLEKTIF_IDR, A.CHARGE_IDR, A.WRITEBACK_IDR, A.IMPAIRED_LOAN_RATIO FROMFACTCKPNCUSTA LEFTJOINDIM_BRANCH_MASTERB ONA.BRANCH_CODE=B.BRANCH_CODE LEFTJOINDIM_SEGMENTC ONA.SEGMENT=C.SEGMENT_LEVEL_3_DESC LEFTJOINDIM_COLLECTIBILITY_MOVEMENTD ONA.KOL_MOV=D.COLLECTMOVEMENT_DESC LEFTJOINDIM_IMPAIRMENT_GROUPE ONA.COLLECTIVE_GROUP=E.IMPAIRMENTGROUP_DESC WHEREDOWNLOAD_DATE='20140131'


186


Lampiran 5 : Contoh data pada tabel fakta loan

Lampiran 6 : Contoh data pada tabel fakta ckpn


187


Lampiran7 :Uji coba nilai total pembiayaan dengan data neraca Bank ‘X’

pada periode Januari 2014.

Lampiran 8 : Uji coba nilai Probability Default dengan metode Net Flow Rate

dan Migration Analysis


188


Lampiran 9 : Uji coba nilai Loss Given Default dengan metode Expected

Recoveries dan Collateral Shortfall


189



190


Lampiran 10 :Uji coba nilai CKPN kolektif per masing-masing collective

impairment group dan kolektibilitas


191


Lampiran 11 : Tanda Tangan Pengguna atas aktivitas Uji Coba Acceptance

dari Implementasi datamart dan OLAP pada Bank X


lib.ui.ac.idlib.ui.ac.id/file?file=digital/2015-3/20392967-ta-alexander rudy.pdflib.ui.ac.id

Documents