Perancangan Modul Klaim Stolen Kendaraan Bermotor

Menggunakan Platform Pega System

di PT. Asuransi Sinarmas

Artikel Ilmiah

Peneliti:
Riyandi Manasye Rafrista Lapod (672014239)
Magdalena A. Ineke Pakereng, M.Kom.

Program Studi Teknik Informatika

Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Salatiga
November 2017
1. Pendahuluan

Teknologi saat ini terus saja berkembang, setiap detiknya selalu muncul
inovasi-inovasi penggunaan teknologi, makin banyak pula framework ataupun tools
yang dapat digunakan untuk membuat sebuah aplikasi. Berkembangnya framework
dan juga tools untuk programming aplikasi membuat beberapa perusahaan
melakukan peralihan (migrasi) aplikasi menggunakan framework yang lebih baru
dan juga lebih sesuai dengan tujuan ataupun proses bisnis yang dilakukan.
Seperti halnya yang dilakukan PT. Asuransi Sinar Mas yang melakukan
migrasi platform dari ASP classic ke pega system, sebuah framework yang berfokus
pada Business Process Management (BPM). Penggunaan pega system kemudian
diterapkan pada salah satu bisnis asuransi simas mobil yaitu klaim asuransi
kendaraan bermotor (klaim MBU). Pada aplikasi lama yang berbasis ASP classic,
proses klaim stolen mempunyai lebih dari 1 aplikasi/ modul berbeda pada beberapa
sumber bisnis untuk melakukan registrasi klaim. Berdasarkan konsep bisnis
asuransi perusahaan, proses pengajuan klaim stolen hampir sama seperti klaim
partial, yang membedakan pada klaim stolen hanyalah ketika proses registrasi
selesai, maka nasabah akan di-interview mengenai kronologis kejadian serta
validasi terhadap dokumen-dokumen penting untuk keperluan laporan klaim [1].
Setelah dilakukan pengecekan serta validasi oleh staff survey MBU, maka proses
akan dilanjutkan oleh staff stolen hingga sampai pada tahap pemeriksaan oleh tim
komite dan selanjutnya ke tahap pembayaran/ akseptasi. Kendala muncul saat
aplikasi yang lama belum dapat memproses keseluruhan flow dengan menggunakan
system, sehingga menimbulkan permasalahan pada proses pengisian data
kronologis serta dokumen-dokumen di dalamnya karena beberapa proses yang
penting masih menggunakan cara manual. Hal ini seringkali dapat menyebabkan
terhambatnya proses klaim dikarenakan perbedaan data yang dimiliki oleh simas
mobil dan data yang ada pada nasabah sehingga berpengaruh pada waktu
pemrosesan suatu klaim.
Salah satu keunggulan pega system adalah dapat memproses setiap proses
bisnis suatu program berdasarkan konsep program atau programmed decision logic
yang langsung diproses oleh system sehingga dapat mengurangi manual
intervention [2].
Berdasarkan latar belakang tersebut, maka dilakukan penelitian yang berjudul
Perancangan Modul Klaim Stolen Kendaraan Bermotor Menggunakan Pega
System.

2. Tinjauan Pustaka

Beberapa Penelitian tentang platform pega system dijadikan acuan dalam

penelitian yang akan dilakukan. Penelitian yang berjudul BPM Development for
Insurance Claims Using Pega, membahas bagaimana membuat suatu aplikasi klaim
asuransi berbasis BPM menggunakan Pega dengan tujuan untuk memberikan
kemudahan setiap perusahaan asuransi agar dapat mengatur semua data dan
informasi sejalan dengan perkembangan bisnis. Hasil yang didapat dari penelitian

1
tersebut adalah penggunaan pega system sebagai platform dari aplikasi tersebut
membutuhkan lebih sedikit waktu dan usaha untuk mengembangkan dan
memelihara keseluruhan sistem [3].
Penelitian mengenai Business Process Management in Insurance Case of
Jadransko Insurance Company, membahas tentang bagaimana sebuah bisnis
asuransi dapat berjalan dengan sebuah fleksibilitas serta kemampuan adaptasi
terhadap setiap perubahan serta management dan control sistem secara real time
berdasarkan Balanced Scorecard concept. Hasil yang didapat dari penelitian
tersebut adalah pengelolaan proses bisnis yang berkelanjutan menggunakan tools
berbasis BPM dibutuhkan perusahaan untuk mencapai efisiensi dan efektivitas yang
lebih baik dalam pengambilan keputusan [4].
Penelitian mengenai Automation to Handle Customer Complain in Bank
Using BPM Tool, membahas tentang perancangan aplikasi bank yang
menggunakan platform pega system untuk mengurangi waktu dan meningkatkan
proses otomatis dalam pengolahan data bank, serta dapat mengolah 3,5 juta
complaints satu bulannya. Hasil yang didapat dari penelitian tersebut adalah
aplikasi yang menggunakan platform pega system dapat mengolah 3,5 juta
complaints satu bulannya dan terdapat peningkatan kinerja 70% dan SLA 15%
lebih cepat jika dibandingkan dengan aplikasi sebelumnya [5].
Penelitian mengenai Analysis Optimization of E-Klaim MBU System in Stolen
Division at PT. Asuransi Sinar Mas, membahas mengenai analisis optimasi klaim
kehilangan pada sistem e-klaim, divisi klaim stolen. Hasil yang didapat dari
penelitian tersebut adalah proses analisis prosedur klaim menunjukkan bahwa
sistem yang lama harus dioptimalkan dari awal proses pengajuan klaim sampai final
decision sehingga dapat meningkatkan waktu pemrosesan suatu klaim dan juga
mengoptimalkan managemen relasi dengan customer [1].
Berdasarkan penelitian-penelitian terdahulu tentang perancangan aplikasi
menggunakan platform pega system, maka dilakukan penelitian tentang
perancangan modul klaim stolen untuk mendukung dalam proses klaim mulai dari
registrasi klaim, survei, approval dari tim komite hingga ke tahap
akseptasi/pembayaran klaim serta semua validasi klaim berdasarkan prosedur
klaim kendaraan bermotor PT. Asuransi Sinar Mas dengan menggunakan platform
pega system. Berbeda dengan modul klaim stolen yang sebelumnya yang proses
klaimnya dilakukan secara manual dan terpisah pada beberapa proses, pada modul
klaim stolen yang baru dirancang untuk memproses setiap klaim secara pararel
serta all by system. Sehingga dalam proses pelaporan klaim, semua data klaim bisa
terintegrasi ke semua modul serta memudahkan user memproses klaim tersebut
secara cepat dan efektif.
Siklus dari BPM biasanya mencakup desain, model, eksekusi, monitor dan
pengoptimalan. Secara kasar, PRPC menggabungkan ketiga langkah pertama
menjadi satu dan kemudian meningkatkan kecepatan proses pengembangan yang
memungkinkan perusahaan lebih fokus kepada optimasi system dan interaksi
dengan customer. Pega PRPC (Pega Rules Process Commander) adalah sebuah
platfom yang mengotomatisasikan proses berjalannya system serta programming.
Seperti halnya ketika suatu tim melakukan pemrograman terhadap beberapa modul

2
secara terpisah, PRPC menawarkan suatu designer-studio yang digunakan bersama
untuk mengembangkan serta menguji semua modul [6].
Pega System adalah satu dari beberapa platform yang pure-play dalam BPM
dan salah satu platform yang paling established. Pega System memiliki pendekatan
berbeda dengan kebanyakan product BPM lainnya dan lebih mendukung dalam
proses pencarian solusi based on BPM. Pendekatan solution-oriented oleh pega
system juga membawanya lebih fokus kepada case management yang mana
terintegrasi dalam BPM dari pega system [7].
Tabel 1 Fungsi, Karakteristik, dan Solution Extensions dari BPM Pega System [7]

Pega system memiliki fungsi, karakteristik dan juga solusi tambahan yang
mendukung kinerja dari platform tersebut (Tabel 1). Pega system menawarkan suatu
Designer-Studio yang diperlukan dalam semua proses design program dan juga
sebuah tools yang dapat digunakan oleh business user dan technical user, baik
digunakan untuk menyelesaikan suatu proses, kebijakan, user interactions, maupun
rules dan integrations [7].
Metodologi yang digunakan dalam mendukung perancangan modul
kehilangan adalah Pega Scrum Methodology yaitu metodologi yang diterapkan
pada proses perancangan project klaim MBU simas mobil yang di dalamnya
terdapat modul klaim stolen. Metode ini dirancang untuk sebuah perusahaan atau
organisasi dalam menentukan bagaimana perusahaan mendefinisikan dan
mengelola suatu product. Pega Scrum sendiri mempunyai pendekatan yaitu, Agile
and iterative, Releases capabilities quickly, Focuses on business value and results,
Empowers resources and invites change, Evolves and changes based on the project.
Metode Pega Scrum cocok diimplementasikan pada kondisi, yaitu ingin mencapai
suatu hasil dengan cepat, fokus pada kualitas suatu produk, proses bisnis yang dapat

3
terlibat penuh selama proses pengembangan product berlangsung, komitmen
perusahaan pada Scrum, dan sebuah tim yang terampil dan aktif [8]. Pada proses
pengerjaan dan perancangan project klaim kendaraan bermotor simas mobil,
terdapat modul-modul yang mendukung proses bisnis dari perusahaan. Penggunaan
pega sebagai tools dalam merancang product tersebut dapat memaksimalkan waktu
dalam pembuatannya serta menghasilkan suatu product yang mempunyai kualitas
yang tinggi. Metode pega scrum menyebabkan proses bisnis yang seringkali
berubah-ubah dapat dengan cepat dan mudah diadaptasikan dan disesuaikan pada
flow program yang telah ada sebelumnya.

Gambar 1 Proses dari Pega Scrum Methodology [8]

Gambar 1 menunjukkan proses pada Pega Scrum Methodology, dijelaskan

sebagai berikut:
1. Vision Definition - Mengembangkan pemahaman tentang gambaran besar
untuk anggota tim, peta jalannya proyek dan backlog produk.
2. Project Initiation - Menentukan lingkup proyek awal dan menetapkan
harapan dari proyek.
3. Enterprise Planning - Merancang infrastruktur yang dibutuhkan untuk
mendukung kemampuan dan kebutuhan masa depan dan juga struktur kelas
perusahaan yang mendukung penggunaan ulang maksimum saat penerapan
diterapkan.
4. Release Implementation - Membangun aplikasi secara cepat menggunakan
pendekatan Scrum untuk pengembangan aplikasi.
5. Release Retrospective - Mengevaluasi, menyesuaikan, dan memperbaiki
proses secara terus menerus.

3. Metode dan Perancangan Sistem

Secara umum penelitian terbagi ke dalam empat tahap, yaitu: (1) tahap
Identifikasi Masalah, (2) tahap Perancangan Sistem Menggunakan Pega System, (3)
tahap User Testing dan Pengujian Sistem, (4) tahap Implementasi dan Operasional
Sistem.

4
 Identifikasi Masalah

Perancangan Sistem Menggunakan Pega System

User Testing dan Pengujian Sistem

Implementasi dan Operational Sistem

Gambar 2 Tahapan Penelitian [12]

Tahapan penelitian dapat dilihat pada Gambar 2 dan dijelaskan sebagai

berikut : Langkah pertama dalam tahapan penelitian adalah identifikasi masalah,
pada tahap ini dilakukan analisis mengenai masalah-masalah yang terjadi dalam
modul klaim stolen pada sistem e-klaim yang terdahulu, serta penentuan batasan-
batasan masalah. Berdasarkan wawancara maupun serangkaian pertemuan dengan
business user untuk membahas modul tersebut, dapat diambil beberapa batasan
masalah yaitu, proses registrasi tidak membutuhkan nomor referensi dari pihak
leasing namun hanya dilakukan validasi pada nomor polis nasabah/tertanggung.
Proses registrasi dilakukan on system baik di kantor pusat maupun cabang, proses
pengisian data dan validasi dokumen pada data registrasi dan survey tidak
menggunakan manual tetapi by system, dan modul yang berhubungan dengan klaim
stolen sendiri ada 4 yaitu, modul surveyor, modul komite, modul akseptasi dan
modul compliance. Langkah yang kedua dari tahapan penelitian adalah
perancangan sistem. Perancangan sistem dilakukan dengan proses perancangan
UML diagram yaitu use case diagram yang meliputi alur proses klaim kendaraan
bermotor (klaim MBU) jenis kejadian stolen. Sistem yang dibangun pada penelitian
kali ini menggunakan platform pega system. Berdasarkan use case diagram
tersebut, setiap workflow bisnis diimplementasikan ke dalam pega system dengan
menggunakan fungsi bawaan seperti case modul, workflow, flow action, activity,
user interface, report definition dan fungsi lainnya. Langkah yang ketiga dari
tahapan penelitian adalah pengujian sistem. Langkah ini dilakukan dalam beberapa
tahap meliputi user application testing (UAT) dan Pararel Test. Pada proses UAT,
system akan didemokan kepada user sambil dilakukan analisis terkait hasil review
dari sistem tersebut. Sedangkan untuk pararel test, user diinstruksikan untuk
melakukan review sistem sambil mengeoperasikan sistem tersebut pada jangka
waktu yang ditentukan. Program yang di-review pada tahap pararel test adalah
program yang telah direvisi dan telah disetujui oleh developer dan business user.
Langkah ini merupakan tahapan lebih lanjut dari tahapan perancangan sistem
berdasarkan metodologi pega scrum. Sistem yang sudah dirancang akan di-review
oleh setiap business user untuk mengetahui setiap progress serta penerapan konsep
bisnis tersebut pada program yang telah dibuat sehingga sesuai dengan pemahaman
konsep bisnis perusahaan. Langkah yang terakhir adalah tahapan implementasi
program. Setelah keseluruhan program selesai diuji, maka program tersebut akan

5
dijalankan serentak untuk semua modul pada klaim kendaraan bermotor PT.
Asuransi Sinar Mas. Selama tahap ini berlangsung, tahapan operational system akan
berjalan seiiring dengan perkembangan bisnis dalam perusahaan.
Perancangan proses pada modul klaim stolen menggunakan diagram unified
Modelling Language (UML), yaitu Use Case Diagram, Activity Diagram dan Class
Diagram. Use case diagram merupakan diagram yang menspesifikasikan perilaku
sistem dan merupakan deskripsi dari sekumpulan aksi yang diharapkan oleh calon
pengguna sistem/perangkat lunak yang akan dikembangkan [12].

Approval Tim Stolen

Upload Dokumen
User Estimator Stolen Tambahan <<extend>>
<<include>>
<<extend>>
Surveyor Review oleh Komite
Mobile/ Web
Survey Luar <<extend>> Review Klaim Stolen

<<include>> <<extend>> <<extend>>

<<include>> <<include>> <<extend>>
User Komite

Telepon <<include>> Registrasi Klaim <<extend>> Input Data Klaim <<extend>> Tolak Klaim Approval Komite

<<extend>>
Nasabah <<include>>
<<extend>>
<<include>> Upload Dokumen Klaim
Kehilangan Approval Pembayaran
<<include>> <<extend>> Klaim oleh Akseptor
Data Saksi dan BAP
Nasabah
<<include>>
Akseptor
Data Polis Valid &
Masih Aktif

Pembayaran Klaim/
Datang
Pilih Kejadian Account Bank dari <<extend>> Akseptasi
Langsung <<extend>> Kehilangan Tertanggung / Leasing
Random Surveyor
User Klaim Stolen

Gambar 3 Use Case Diagram Flow Klaim Langsung/Stolen

Gambar 3 menunjukkan use case diagram yang akan digunakan pada sistem.
Dalam proses registrasi klaim pada klaim MBU, terdapat 3 jalur berbeda yaitu
registrasi via datang langsung, registrasi via telepon, dan registrasi via web/ mobile.
Proses registrasi klaim secara langsung, nasabah melaporkan kejadian dengan
mendatangi langsung kantor simas mobil yang ada di pusat maupun di cabang.
Sedangkan klaim melalui telepon, proses registrasi serta pengisian data kejadian
berdasarkan hasil interview dan proses survei dilakukan setelah proses tersebut.
Dalam use case diagram tersebut terdapat 5 user. Pertama user surveyor, user yang
memiliki role serta tanggung jawab untuk melakukan survei terhadap data yang
telah diregistrasi. Kedua user estimator stolen, yang berfungsi sebagai reviewer dari
klaim stolen. Ketiga user komite, memiliki kewenangan menentukan dan memberi
persetujuan nilai klaim berdasarkan data klaim yang diajukan surveyor. Keempat
user akseptasi, memiliki tugas untuk melakukan verifikasi data pembayaran klaim,
dan yang terakhir adalah user klaim stolen, user/admin yang dapat melakukan
proses registrasi khusus untuk klaim stolen.
Acticity diagram merupakan diagram yang menggambarkan berbagai alir
aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir
berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir [12].

6
 Activity Diagram User Surveyor & Stolen

User Stolen User Surveyor

Review Klaim

Set Dokumen Auto

Aksep Stolen

Perlu
Survey YA
Input Kelengkapan
Luar Dokumen
TIDAK

Liable TIDAK

Liable
YA TIDAK

Transfer Case ke YA
Komite
Transfer Case ke
Komite
Phase

Gambar 4 Activity Diagram Proses Review Klaim Stolen Jika Perlu Survey Luar

Gambar 4 merupakan activity diagram proses review klaim stolen. Dalam

proses tersebut, user stolen dapat menentukan klaim tersebut perlu untuk survey
luar atau tidak. Proses tersebut bertujuan untuk melengkapi data kronologis ataupun
dokumen-dokumen pendukung klaim. Pada flow surveyor, user yang bersangkutan
memiliki hak dalam memberi keputusan terkait liable tidaknya klaim tersebut.
Perihal mengenai status liable, staff surveyor harus dapat mengidentifikasi
beberapa fakta yang ditemukan pada laporan klaim. Indikasi yang harus diperiksa
adalah; 1) Apakah mobil tersebut sudah dijual ke orang lain; 2) Penggunaan
kendaraan yang tidak sesuai dengan polis asuransi; 3) Kendaraan tersebut telah
dicuri oleh kerabat atau keluarga tertanggung [1].

Activity Diagram User Stolen & Komite

User Komite User Stolen

Review Detail
Klaim

Input Kelengkapan
TIDAK
Dokumen

Approval

Pengajuan Ulang
Komite
YA

Tolak Klaim

Update History
Transfer Case ke Pengajuan
TIDAK
Akseptasi

YA
Phase

Gambar 5 Activity Diagram Proses Pengajuan Ulang Komite

Gambar 5 merupakan activity diagram proses pengajuan ulang komite. Saat

berada dalam komite, user komite akan melakukan review detail klaim untuk

7
persetujuan nilai klaim. Ketika user komite memutuskan untuk tidak setuju, maka
case tersebut akan kembali ke tim stolen untuk diperiksa kembali detail klaim
tersebut. Proses tersebut akan berulang terus jika user stolen maupun user komite
tidak memutuskan untuk menolak klaim.

JSON_POLIS
-TGL_INPUT : DATE
-DATA_JSON : CLOB
JSON_KLAIM
-NOPOLIS : VARCHAR2
-MNK_NO_KLAIM : VARCHAR2
-NOSPAK : VARCHAR2
-DATA_JSON : CLOB
-PRODKE : VARCHAR2
-IDPEGA : VARCHAR2
-ERR_NOTE : VARCHAR2
-TGL_INPUT: TIMESTAMP
-TGL_KONVERSI : DATE2
-TGL_KONVERSI : DATE
-IDPEGA : VARCHAR2 1 * -NOPOLIS : VARCHAR2
-STS_KONVERSI : NUMBER
-IDPROD : INTEGER
-OBJECTDATA : CLOB
-POLICYDATA : CLOB -Insert()
-RENEWAL : CLOB -Update()
-View()
-Insert()
-Update()
-View()

Gambar 6 Class Diagram dari Modul Registrasi Klaim MBU

Gambar 6 merupakan class diagram dari modul registrasi klaim MBU. Setiap
class pada Gambar 6 menunjukkan setiap komponen yang dibutuhkan pada sistem
yang mana akan dijadikan sebagai acuan pembuatan tabel pada database sistem.
Sistem akan menggunakan relasi one-to-many antar class.

4. Pembahasan dan Hasil Pengujian

Pada proses implementasi proses bisnis dari klaim stolen, maka dibuatlah
sebuah flow process untuk diterjemahkan ke dalam sistem dengan menggunakan
Designer-studio pega system versi 7.2.2. Proses yang akan dibahas adalah
pengajuan klaim secara langsung/direct claim atau registrasi dari dokumen klaim
yang diajukan leasing. Pada tahap ini akan dijelaskan workflow dari direct claim.

Gambar 7 Flow Processing Klaim MBU Via Direct Claim

8
 Flow mewakili sebuah representasi proses bisnis suatu perusahaan. Flow
mengidentifikasi cara kerja sistem tersebut, cara pengambilan keputusan, dan
proses apa saja yang terjadi secara otomatis dan bagaimana suatu proses
terselesaikan. Flow berisikan suatu jaringan tugas seperti assignment, decision,
utilities dan connector [10].
Gambar 7 menjelaskan tentang flow processing dari klaim MBU dimana
proses awal dimulai dari start dan diikuti dengan beberapa assignment atau decision
sesuai dengan proses bisnis klaim. Flow klaim direct pada Gambar 7 dijelaskan
secara detail sebagai berikut. Pertama yaitu validasi decision, apakah user yang
melakukan registrasi adalah user klaim phone, jika tidak maka akan masuk ke
assignment data polis untuk melakukan pengisian form registrasi klaim.
Selanjutnya decision untuk pengecekan jenis klaim, direct claim atau phone. Jika
direct claim, case tersebut akan masuk ke assignment pilih area klaim. Ketika
pindah ke assignment pilih surveyor, terdapat suatu fungsi untuk melakukan
random surveyor by system. Setelah mendapatkan surveyor, maka proses berlanjut
pada pembuatan case untuk surveyor.
Pada proses untuk menampilkan section serta fungsi di suatu assignment,
terdapat suatu fungsi yaitu flow action, suatu method yang digunakan untuk
mengelola suatu task ke user yang ditampilkan berdasarkan activity yang dijalankan
pada pre-processing dan post-processing [10].
Terdapat 2 activity serta 1 data transform yang digunakan untuk mengelola
assignment data polis. Data transform inputclaiminformation_preDT dan activity
setincidenttype_Act digunakan untuk menempatkan suatu nilai pada property
sebelum assignment tersebut ditampilkan. Kemudian fungsi dari activity
claimdatacheck_act adalah menempatkan suatu property pada post assignment data
polis. Property tersebut disimpan pada suatu clipboard yang dalamnya terdapat data
dan class untuk dijalankan oleh system. Value dari property tersebut akan
membantu memproses keseluruhan assignment yang ada pada flow tersebut.

Gambar 8 Tampilan Form Registrasi dan View Data Polis Klaim MBU

9
 Gambar 8 menunjukkan tampilan form registrasi klaim saat masuk ke dalam
assignment data polis. Dalam section ini, khusus klaim stolen, masukan untuk klaim
terbagi dua yaitu, klaim melalui telepon dan klaim secara langsung. Kemudian
untuk masukan pilih tertanggung/TJH, default value-nya adalah tertanggung
sebagaimana klaim ini adalah klaim stolen yang hanya melibatkan kendaraan milik
tertanggung yang bersangkutan. Terdapat juga text input untuk pencarian data polis
yang memungkinkan user mencari data berdasarkan salah satu dari nomor mesin,
nomor rangka, nomor polis atau nomor plat. Registrasi untuk klaim stolen ataupun
partial hanya melibatkan nasabah yang telah memiliki nomor polis dan memiliki
nilai own risk yang tidak kosong.
Pada tampilan view data polis, input jenis kejadian dipilih berdasarkan
kronologi yang dialami oleh tertanggung. Dalam kasus ini, jenis kejadian tersebut
adalah kehilangan/stolen. Pada proses pencarian data polis tersebut, system akan
menjalankan sebuah activity atau prosedur untuk pengecekan terhadap validasi
polis tertanggung sehingga data yang ditampilkan adalah data yang sudah
tervalidasi oleh system sesuai dengan prosedur pengajuan klaim asuransi simas
mobil PT. Asuransi Sinar Mas. Pada tahapan sebelum masuk ke pemilihan area
klaim, terdapat fungsi auto complete Polsek dan Polres yang wajib diisi untuk acuan
input wilayah klaim di-assignment selanjutnya.
Tahapan selanjutnya adalah proses penentuan wilayah klaim dan surveyor
dari case tersebut. Proses ini dilakukan otomatis by system ketika perpindahan
assignment dari pilih area ke random surveyor. Pada activity post-processing
assignment pilih area, keseluruhan step di dalamnya akan memproses pengecekan
jumlah surveyor berdasarkan value dari property wilayah klaim, sehingga pada pre-
processing assignment pilih surveyor, data surveyor tersebut divalidasi lagi sesuai
dengan property status aktif dan finish claim dari surveyor yang ada. Dalam logika
pemrosesannya jika data status aktif dan finish claim pada salah satu surveyor
tersebut bernilai “1”, maka system akan secara otomatis memilih surveyor tersebut.
Proses kemudian akan berlanjut pada flow surveyor dimana case yang telah
diregistrasi dan telah mendapatkan surveyor, masuk ke dalam inbox surveyor untuk
menjalankan proses pengisian data kronologis dari tertanggung. Flow surveyor
ditunjukkan pada Gambar 9.

Gambar 9 Flow Surveyor

10
 Berdasarkan alur flow dari klaim stolen, case yang telah selesai diregistrasi
akan masuk pada flow tim surveyor untuk melakukan proses survey terhadap
laporan klaim yang telah diregistrasi. Penjelasan alur dari flow createsurveyor_flow
pada Gambar 9.
1. Jika case tersebut adalah klaim secara langsung, dan pengajuan dari tertanggung
serta jenis kejadian adalah kehilangan, maka akan dijelaskan seperti berikut;
START DS isklaimphone v[else] DS isalreadyroute v[true]
AG Startscreenflowauto DS istempclaim v[else] SP InputKlaim

Keterangan:

DS = Decision

V = Value

SP = Subprocess

AG = Assignment

IsKlaimPhone = registrasi by phone

IsAlreadyRoute= operator id untuk surveyor

Istempclaim= tidak punya nomor polis

Case kemudian akan masuk ke dalam sub process input klaim yang di
dalamnya terdapat diagram flow untuk menjalankan workflow dari proses survey.
Flow tersebut akan dijelaskan pada Gambar 10.

Gambar 10 Flow Surveyor di Dalam Sub Process Input Klaim

Case yang telah melewati flow serta memenuhi rule pada flow
createsurveyor_flow (Gambar 9), akan diproses kembali pada flow input klaim
dimana user surveyor akan mengisi setiap text input seperti data pelapor, data
kejadian serta data konfirmasi sesuai dengan flag serta decision yang ada pada tiap
assignment flow. Dalam kasus klaim stolen, case tersebut akan melewati beberapa
assignment seperti yang akan dijelaskan berdasarkan Gambar 10.

11
2. Apabila case tersebut adalah dari klaim stolen dan bukan dari inbox stolen, maka
assignment serta decision yang akan dilewati sebagai berikut:

START AG Data Polis DS isAlreadyRoute v[true] AG Data Pelapor

AG Data Kejadian DS isStolen v[true] DS isChooseSurvey
v[else] AG Konfirmasi DS isStolen v[true] DS isFromInboxStolen
v[else] END

Setelah memenuhi rule dan flag pada flow tersebut, selanjutnya case akan keluar
dari flow input klaim dan masuk kembali ke flow CreateSurveyor_Flow, proses
tersebut bisa dilihat pada Gambar 18.

Gambar 11 Flow CreateSurveyor Ketika Case Keluar dari Flow Input Klaim

3. Case akan melalui beberapa decision dan assignment berdasarkan property dan
flag yang telah di-set di dalam flow input klaim. Alur dari flow ini akan dijelaskan
sebagai berikut;
DS isUserAssignEqualsWithOperatorID v[true] DS isStolen v[true]
DS isFromInboxStolen v[else] AG Inbox Stolen SP Input Klaim.
Keterangan:
DS = Decision

V = Value

SP = Subprocess

AG = Assignment

IsStolen = jenis klaim stolen

IsAlreadyRoute = operator id untuk surveyor

IsChooseSurvey = pernah memilih untuk survey

IsFromInboxStolen = case berasal dari Inbox Stolen

IsUserAssignEqualsWithOperatorID = user surveyor sama dengan login aplikasi

12
 Saat case berada pada assignment inbox stolen, maka case tersebut telah siap
untuk dilakukan review klaim berdasarkan hasil yang di-input oleh surveyor. Hal
tersebut terjadi dikarenakan ada proses routing saat case ditransfer ke inbox stolen.
Portal tersebut hanya dapat diakses oleh user yang memiliki access group inbox
stolen dan workgroup klaim stolen serta login aplikasi yang terdaftar pada pega
system.

Gambar 12 Tampilan Menu dan Fitur di Portal Inbox Stolen

Gambar 12 menunjukkan tampilan menu dan fitur di portal inbox stolen.

Setiap case yang masuk ke inbox stolen akan ditampilkan pada section ini.
Tampilan ini disebut list inbox workbasket yaitu list yang menampung tiap antrian
case yang di-assign ke workgroup klaim stolen. Case yang ada dalam workbasket
merupakan case yang telah ditransfer oleh admin phone atau surveyor. Jika salah
satu case diambil, maka case tersebut akan berpindah ke dalam worklist, yaitu list
aktif yang menampung setiap case yang diambil dari workbasket.
Pada inbox stolen terdapat beberapa fitur serta fungsi yang dapat dilakukan
oleh user tersebut. Selain menampilkan menu my work, terdapat inbox pengajuan
komite ulang, yaitu inbox yang menampilkan case yang tidak disetujui oleh komite
khusus klaim stolen. Case tersebut akan masuk kembali ke tim stolen untuk
melakukan review kembali sesuai instruksi/pesan dari staff MBU komite.
Pada tampilan data kronologis pada inbox stolen, terdapat fungsi tambahan
untuk memeriksa kelengkapan dokumen klaim, yaitu review auto aksep stolen.
Fungsi auto aksep dalam klaim stolen menjadi acuan saat proses klaim tersebut
berada diakseptasi/payment. Pembayaran klaim bersumber pada 3 variabel yaitu
nilai ganti rugi (TSI/ Var value), pinalti dokumen, dan resiko sendiri.

13
 Gambar 13 Tampilan Review Dokumen Auto Aksep Stolen

Ada beberapa option dan validasi dalam review pada Gambar 13. Pertama
yaitu user estimator dapat menentukan klaim tersebut liable atau tidak berdasarkan
data hasil dari tim survei. Kedua, user dapat melihat posisi kredit dari tertanggung,
lunas atau belum. Keterangan kredit lunas dari data polis tertanggung dilakukan
validasi saat proses review klaim stolen. Ketiga, ada beberapa dokumen yang harus
diperiksa kelengkapannya sesuai data yang di-upload saat survei. Dokumen yang
ditampilkan divalidasi sesuai dengan sumber bisnis dari tertanggung. Jika
tertanggung mempunyai sumber bisnis A dimana dokumen persyaratan klaim yang
dibutuhkan hanya 2 seperti STNK, SIM, maka yang dimunculkan hanya kedua
dokumen tersebut. Proses tersebut menggunakan fungsi report definition untuk
mengambil semua data yang ada pada view database berdasarkan sumber bisnis
tertentu. Keempat, yaitu opsi tolak klaim, yaitu option yang dapat dipilih user jika
menemukan suatu kejanggalan dalam klaim tersebut yang tidak sesuai dengan
prosedur klaim simas mobil. Jika klaim ditolak, maka case klaim tersebut
dinyatakan finish atau resolved-completed pada pega. System juga secara otomatis
akan mengirim surat tolakan ke email tertanggung/leasing menggunakan activity
send simple email dan fungsi html dari pega system. Setelah proses tersebut, setiap
case dalam modul stolen akan ditutup dan dibuka kembali case-nya jika diajukan
pengajuan ulang klaim exgratia. Button hitung pinalty memungkinkan user untuk
menghitung jumlah pinalti pada beberapa kelengkapan dokumen yang tidak ada
pada klaim tersebut. Default dari tiap dokumen pada dropdown tersebut yaitu
“ADA”.
Data klaim stolen yang dibutuhkan seperti data saksi dan data stolen dapat di-
review juga pada tampilan section data kejadian. Setelah itu user stolen dapat
menentukan apakah klaim tersebut harus dilakukan survei lagi atau tidak dengan
berdasarkan kelengkapan dokumen seperti survey report, foto TKP, denah TKP,
data saksi serta data BAP stolen pada klaim tersebut. Jika user memutuskan untuk
melakukan survei ulang, maka proses akan berpindah ke dalam inbox surveyor
untuk dilakukan survei kembali. Proses pengajuan case ke inbox surveyor sama
seperti ketika melakukan pemilihan wilayah klaim dan random surveyor saat proses
registrasi klaim. jika user memutuskan klaim liable dan tidak perlu dilakukan survei
ulang, maka klaim tersebut akan berlanjut pada proses menunggu approval oleh
staff komite klaim MBU.

14
 Pada pega system terdapat suatu fungsi yaitu Agents, yaitu fungsi
penjadwalan otomatis oleh system [10]. Dalam fungsi tersebut, agents menjalankan
suatu activity pada class yang ditentukan. Activity ini berfungsi untuk menjalankan
sebuah fungsi dalam modul komite, khusus jenis klaim stolen. Setiap sumber bisnis
dalam suatu nomor polis mempunyai SLA (Service Level Agreement) yaitu jumlah
hari kerja yang ditetapkan pada suatu klaim yang berjalan sesuai dengan
persetujuan pihak ASM dan sumber bisnis terkait. Proses auto approve by system
akan berjalan ketika case yang sudah diregistrasi telah melewati SLA suatu sumber
bisnis. Proses akan berjalan ketika jumlah hari sejak case komite dibuat sampai
rentang waktu batas klaim dari sumber bisnis tertentu sudah melebihi batasan
jumlah hari pada SLA sumber bisnis tersebut. Sistem lewat agents akan otomatis
menjalankan activity pada setiap case yang mempunyai data SLA pada sumber
bisnisnya. Proses tersebut menggunakan fungsi report definition, yaitu proses
pengambilan data pada view database atau data yang ada dalam kelas tertentu [10].

Gambar 14 Activity Agents SLA Komite Stolen

Gambar 14 merupakan activity agents SLA komite stolen. Ketika proses auto
approve komite selesai, maka case tersebut sudah berubah statusnya menjadi
resolved completed. Jika komite setuju pada salah satu case klaim stolen, maka akan
dibuat satu case akseptasi untuk proses pembayaran klaim. Jika kredit kendaraan
tertanggung lunas, maka pembayaran klaim tersebut adalah ke tertanggung,
sedangkan jika kredit kendaraan belum lunas, maka pembayarannya ke
leasing/sumber bisnis pada polis tertanggung tersebut. Proses akseptasi langsung
berhubungan dengan hasil dari review dokumen aksep stolen.
Serangkaian proses dari klaim stolen merupakan bagian sistem registrasi
klaim MBU secara langsung (direct claim). Proses pengajuan klaim stolen dapat
juga melalui klaim via telepon/by phone. Keseluruhan proses hampir sama seperti
klaim langsung, yang berbeda adalah pengisian data kronologis kejadian langsung
melalui interview dengan tertanggung melalui telepon. Data yang telah selesai diisi
oleh user phone kemudian akan ditransfer ke dalam inbox stolen untuk dilakukan
review klaim. Beberapa validasi dan juga text input dalam section klaim phone
hampir sama dengan proses klaim direct hanya ditambahkan script interview di tiap
section-nya untuk mempermudah user melakukan interview dengan
nasabah/tertanggung tersebut.

15
 Perbandingan modul stolen baru dan modul stolen lama yang dirangkum
berdasarkan poin-poin penting, ditunjukkan pada Tabel 2.

Tabel 2 Perbandingan Modul Klaim Stolen Lama dan Modul yang Baru

No Perbedaan Stolen Lama Stolen Baru

Registrasi menggunakan
Registrasi dilakukan
1 Registrasi aplikasi dengan modul
menggunakan 1 modul
yang berbeda
Dokumen yang di- Setiap dokumen yang di-
Upload Dokumen
3 upload tidak langsung upload, langsung di-generate
dan Metadata
di-generate metadatanya metadatanya
Pengajuan klaim Pada modul klaim via
menggunakan telepon telepon, seluruh proses serta
4 Survey by Phone belum terintegrasi data yang diproses
dengan keseluruhan terintegrasi dengan
system keseluruhan sistem
Masih dalam
5 Aplikasi Mobile Sudah diterapkan oleh system
pengembangan
Belum bisa generate Di-generate melalui sistem
Generate Surat
otomatis serta dengan format pdf dan bisa
6 Tolakan dan SPGR
pengiriman surat lewat langsung terkirim ke email
dan Email
email melalui system tujuan

Pengujian modul dilakukan untuk menguji fungsi-fungsi modul hasil

implementasi. Pengujian yang dilakukan terdiri dari blackbox testing, compatibility
testing, dan usability testing. Blackbox Testing dilakukan untuk mengetahui bahwa
semua fungsi dan fitur pada modul bekerja dengan tepat. Pengujian dilakukan
dengan cara melihat fungsi-fungsi pada modul, kemudian membandingkan hasil
pengujian dengan hasil yang diharapkan. Hasil dari blackbox testing ditunjukkan
pada Tabel 3.

Tabel 3 Hasil Blackbox Testing

No Deskripsi Hasil yang Diharapkan Hasil yang
Diberikan
Modul
1 User dapat melakukan Data yang ditampilkan sesuai Sesuai yang
registrasi klaim dengan data dari master pada diharapkan.
menggunakan nomor database
polis, nomor rangka,
nomor mesin, dan
nomor plat
2 User dapat melakukan User klaim phone dan user stolen Sesuai yang
registrasi via direct dapat melakukan proses registrasi diharapkan.
maupun by phone sampai ke tahap review klaim
stolen
3 User dapat memproses User dapat langsung melakukan Sesuai yang
klaim saat random proses random surveyor dengan diharapkan.

16
 surveyor berdasarkan berdasarkan wilayah Polres dan
Polres dan Polsek Polsek
4 Agents bisa berjalan di User dapat melihat case yang telah Sesuai yang
background system melewati proses auto approve by diharapkan.
sesuai dengan SLA system
leasing tertentu
5 User dapat melihat dan User dapat melihat dan Sesuai yang
mengunggah dokumen mengunggah dokumen walaupun diharapkan.
pada review klaim proses unggah dokumen di modul
stolen yang berbeda
6 User dapat mengajukan User dapat melakukan pengajuan Sesuai yang
kembali case yang kembali case yang tidak disetujui diharapkan.
tidak disetujui oleh ke tim komite serta dapat melihat
komite history pengajuan
7 Validasi klaim saat Validasi terhadap data polis Sesuai yang
registrasi klaim dan tertanggung sesuai dengan diharapkan.
saat proses survey prosedur pengajuan klaim MBU

Berdasarkan hasil blackbox testing pada Tabel 3, disimpulkan bahwa

fungsi-fungsi pada modul bekerja sesuai dengan yang diharapkan/direncanakan.
Compatibility testing dilakukan untuk mengetahui apakah sistem dapat
dijalankan pada berbagai jenis internet browser. Hasil pengujian ditampilkan pada
Tabel 4.
Tabel 4 Hasil Compatibility Testing

No Browser Hasil

1 Internet Explorer V

2. Mozilla Firefox V

3. Chrome V
4. Safari V
5. Opera V

Berdasarkan hasil compatibility testing pada Tabel 4, disimpulkan bahwa

modul dapat berkerja pada semua browser.
Usability Testing dilakukan untuk mengetahui apakah sistem telah
memenuhi kebutuhan pengguna, mempermudah kinerja pengguna dan mudah
digunakan oleh pengguna. Untuk mengetahui hasil usability testing bagi sistem ini,
digunakan kuesioner dengan 13 pertanyaan yang dibagi dalam 3 kategori
pertanyaan yaitu 4 pertanyaan untuk kategori Kegunaan Sistem/System Usability
(SYSUSE), 5 pertanyaan untuk kategori Kualitas Informasi/Information Quality
(INFOQUAL) dan 4 pertanyaan untuk kategori Kualitas Antarmuka/Interface
Quality (INTERQUAL). Jawaban dari kuesioner bagi sistem ini menggunakan
skala Likert dengan pilihan jawaban Kurang dengan nilai 1, Cukup dengan nilai 2,
Baik dengan nilai 3. Skala Likert adalah skala yang digunakan untuk mengukur
sikap, pendapat, dan persepsi seseorang maupun kelompok mengenai sebuah
peristiwa atau fenomena sosial, berdasarkan definisi operasional yang digunakan

17
oleh peneliti [1]. Daftar pertanyaan pada kuesioner yang digunakan ditampilkan
pada Tabel 5.

Tabel 5 Hasil Usability Testing

No Pertanyaan
Kegunaan Sistem/System Usability (SYSUSE)
1 Secara keseluruhan, saya puas dengan fungsi serta validasi yang ada pada modul.

2 Penggunaan modul ini cukup mudah digunakan.

3 Saya dapat menyelesaikan pekerjaan dengan menggunakan modul ini.

4 Mudah untuk belajar menggunakan modul ini.

Kualitas Informasi/Information Quality (INFOQUAL)

5 Modul ini memberikan pesan kesalahan yang dengan jelas memberitahu
bagaimana untuk memperbaiki masalah dengan cepat.

6 Informasi (seperti lihat detail klaim, lihat detail polis, lihat history klaim) yang
disediakan dengan modul ini mudah dipahami.

7 Mudah untuk menemukan informasi yang saya butuhkan.

8 Informasi yang disediakan untuk modul ini mudah dimengerti.

9 Informasi yang disediakan cukup efektif dalam membantu saya menyelesaikan

pekerjaan.

Kualitas Antarmuka/Interface Quality (INTERQUAL)

11 Pengaturan dari struktur informasi pada tampilan modul jelas.

12 Antarmuka (UI) dari sistem ini nyaman dilihat.

13 Modul ini memiliki semua fungsi dan validasi sesuai prosedur klaim PT. ASM.

14 Secara keseluruhan, saya puas dengan modul ini.

Kuesioner ditujukan kepada staff karyawan IT PT. Asuransi Sinar Mas yang
berjumlah 6 responden dengan rincian 1 project leader, 1 staf operational, 1 staff
klaim stolen dan 3 programmer (modul surveyor, modul akseptasi dan modul
komite). Hasil kuesioner diolah menjadi hasil pengujian yang ditampilkan pada
Gambar 15, Gambar 16 dan Gambar 17.

18
 KEGUNAAN KUALITAS
SISTEM/SYSTEM INFORMASI/INFOR
USABILITY MATION QUALITY
Kurang Cukup Baik Kurang Cukup Baik

10% 8% 7%
21%

82% 72%

Gambar 15 Presentase Hasil Kuesioner Gambar 16 Presentase Hasil Kuesioner

Kategori Kegunaan Sistem Kategori Kualitas Informasi

KUALITAS
ANTARMUKA/INTERF
ACE QUALITY
Kurang Cukup Baik

5%
21%

74%

Gambar 17 Presentase Hasil Kuesioner

Kategori Kualitas Antarmuka

Berdasarkan hasil usability testing pada Tabel 5 disimpulkan bahwa, untuk

kategori Kegunaan Sistem, 82% responden memberi nilai 2, yang berarti bahwa
modul sudah cukup baik. Untuk kategori Kualitas Informasi, 72% responden
memberi nilai 2, yang berarti modul memberikan informasi dengan cukup baik.
Untuk kategori Kualitas Antarmuka, 74% responden memberi nilai 2, yang berarti
sistem memiliki desain antarmuka yang cukup baik. Secara keseluruhan berarti
semua responden berpendapat bahwa sistem yang dibuat sudah dapat memenuhi
kebutuhan user.

5. Simpulan

Berdasarkan pembahasan, pengujian, dan analisis sistem, maka dapat diambil

kesimpulan sebagai berikut: (1) proses penerapan proses bisnis klaim stolen secara
menyeluruh by system dapat berjalan sesuai prosedur pengajuan klaim MBU; (2)
Validasi serta verifikasi oleh system pada setiap data dalam modul klaim stolen

19
menempatkan fungsi dan tanggung jawab setiap role bisnis kembali seperti
seharusnya. Penggunaan pega system sebagai designer studio dalam merancang
modul ini memiliki banyak keuntungan saat proses perancangan modul.
Keunggulan dari business process management pega system membuat pengujian
serta maintenance terhadap modul stolen dapat berjalan tanpa menghentikan proses
bisnis klaim yang sedang berjalan. Adanya fitur cross platform, salah satunya
seperti penerapan sistem di platform mobile sangat membantu mempercepat proses
klaim kendaraan bermotor asuransi simas mobil PT. Asuransi Sinar Mas. Saran
pengembangan ke depannya adalah membuat proses terintegrasi terkait registrasi
klaim melalui leasing.

6. Daftar Pustaka

[1] Sudarsono. 2009. Analysis Optimization of E-Klaim MBU System in Stolen

Division at PT. Asuransi Sinar Mas. Binus University. Jakarta.
[2] Romanowski, P., Wynn, J., Hegel, K. 2013. Business Process Management,
The Next Wave in Operational Effectiveness.
[3] Chaudhari, Nikhil., Nagpal, A., H, Santhi. 2017. BPM Development for
Insurance Claims Using Pega. Vol. 10, No. 7.
[4] Coric, S., Bara, D. 2014. Business Process Management in Insurance Case
of Jadransko Insurance Company. Vol. 10:866-887.
[5] Antony, G. S. (2016). Automation to Handle Customer Complaints in Bank
Using BPM Tool, Department of Mechanical and Manufacuring
Engineering, Paper 48.
[6] Wynn, T.M. et al. 2009. Business process verification - finally a reality!
Business Process Management Journal. Vol. 15:1 pp. 77-92.
[7] Craggs, S. 2011. Lustratus Research Comparing BPM form Pegasystems,
IBM and TIBCO.
[8] Salaz, S. 2010. The Pega Scrum Methodology.
[9] Idrus, J. 2013. Perbaikan Sistem Penerimaan Klaim Kehilangan Kendaraan
Bermotor Roda Dua Bisnis Leasing Pada PT. Asuransi Sinarmas
Menggunakan Metode Pendekatan Analisa Sistem. Universitas Mercu Buana.
Jakarta Barat.
[10] Pega Discovery Network. 2017. All Topics. Diambil 1 November 2017, dari
https://pdn.pega.com/all-topics.
[11] W.P. Rivan. 2013. Prosedur Klaim Asuransi Mobil di PT. Asuransi Sinar Mas
Kantor Cabang Surakarta. Universitas Sebelas Maret. Surakarta.
[12] Hasibuan, Z. A., 2007. Metodologi Penelitian Pada Bidang Ilmu Komputer
Dan Teknologi Informasi : Konsep, Teknik, dan Aplikasi, Jakarta: Ilmu
Komputer Universitas Indonesia.
[13] Ridwan, Akdon. 2008. Rumus dan Data dalam Analisis Statistika. Bandung:
Alfabeta.
[14] Pressman, R. S. 2012. Rekayasa Perangkat Lunak. Yogyakarta: Andi.

20