Institutional Repository | Satya Wacana Christian University: Perancangan Modul Klaim Stolen Kendaraan Bermotor Menggunakan Platform Pega System di PT. Asuransi Sinarmas

  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 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 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 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.

  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.

  

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 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].

  

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].

  

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].

  

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 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.

  

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.

  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

  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 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 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.

  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. _{V = Value DS = Decision Keterangan: IsStolen = jenis klaim stolen AG = Assignment} SP = Subprocess _{IsFromInboxStolen = case berasal dari Inbox Stolen IsChooseSurvey = pernah memilih untuk survey} IsAlreadyRoute = operator id untuk surveyor IsUserAssignEqualsWithOperatorID = user surveyor sama dengan login aplikasi

  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.

  

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.

  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.

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

  Pengujian dilakukan dengan cara melihat fungsi-fungsi pada modul, kemudian membandingkan hasil pengujian dengan hasil yang diharapkan. Hasil dari

  3 User dapat memproses klaim saat random

  Sesuai yang diharapkan.

  User klaim phone dan user stolen dapat melakukan proses registrasi sampai ke tahap review klaim stolen

  2 User dapat melakukan registrasi via direct maupun by phone

  Sesuai yang diharapkan.

  1 User dapat melakukan registrasi klaim menggunakan nomor polis, nomor rangka, nomor mesin, dan nomor plat Data yang ditampilkan sesuai dengan data dari master pada database

  

Tabel 3 Hasil Blackbox Testing

No Deskripsi Hasil yang Diharapkan Hasil yang Diberikan Modul

  blackbox testing ditunjukkan pada Tabel 3.

  

compatibility testing, dan usability testing. Blackbox Testing dilakukan untuk

mengetahui bahwa semua fungsi dan fitur pada modul bekerja dengan tepat.

  

Tabel 2 Perbandingan Modul Klaim Stolen Lama dan Modul yang Baru

No Perbedaan Stolen Lama Stolen Baru

  Pengujian modul dilakukan untuk menguji fungsi-fungsi modul hasil implementasi. Pengujian yang dilakukan terdiri dari blackbox testing,

  6 Generate Surat Tolakan dan SPGR dan Email Belum bisa generate otomatis serta pengiriman surat lewat email melalui system Di-generate melalui sistem dengan format pdf dan bisa langsung terkirim ke email tujuan

  5 Aplikasi Mobile Masih dalam pengembangan Sudah diterapkan oleh system

  Pada modul klaim via telepon, seluruh proses serta data yang diproses terintegrasi dengan keseluruhan sistem

  4 Survey by Phone Pengajuan klaim menggunakan telepon belum terintegrasi dengan keseluruhan system

  3 Upload Dokumen dan Metadata Dokumen yang di- upload tidak langsung di-generate metadatanya Setiap dokumen yang di- upload, langsung di-generate metadatanya

  Registrasi dilakukan menggunakan 1 modul

  1 Registrasi Registrasi menggunakan aplikasi dengan modul yang berbeda

  User dapat langsung melakukan proses random surveyor dengan Sesuai yang diharapkan.

  surveyor berdasarkan Polres dan Polsek berdasarkan wilayah Polres dan

  V 2.

  

Quality (INTERQUAL). Jawaban dari kuesioner bagi sistem ini menggunakan

  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

  Usability Testing dilakukan untuk mengetahui apakah sistem telah

  V Berdasarkan hasil compatibility testing pada Tabel 4, disimpulkan bahwa modul dapat berkerja pada semua browser.

  5. Opera

  V

  4. Safari

  V

  3. Chrome

  V

  Mozilla Firefox

  1 Internet Explorer

  Polsek

  

Tabel 4 Hasil Compatibility Testing

No Browser Hasil

  dijalankan pada berbagai jenis internet browser. Hasil pengujian ditampilkan pada Tabel 4.

  Compatibility testing dilakukan untuk mengetahui apakah sistem dapat

  Berdasarkan hasil blackbox testing pada Tabel 3, disimpulkan bahwa fungsi-fungsi pada modul bekerja sesuai dengan yang diharapkan/direncanakan.

  

Validasi terhadap data polis

tertanggung sesuai dengan

prosedur pengajuan klaim MBU Sesuai yang diharapkan.

  7 Validasi klaim saat registrasi klaim dan saat proses survey

  Sesuai yang diharapkan.

  User dapat melakukan pengajuan kembali case yang tidak disetujui ke tim komite serta dapat melihat history pengajuan

  6 User dapat mengajukan kembali case yang tidak disetujui oleh komite

  5 User dapat melihat dan mengunggah dokumen pada review klaim stolen User dapat melihat dan mengunggah dokumen walaupun proses unggah dokumen di modul yang berbeda Sesuai yang diharapkan.

  Sesuai yang diharapkan.

  4 Agents bisa berjalan di background system sesuai dengan SLA leasing tertentu User dapat melihat case yang telah melewati proses auto approve by system

  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 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.

  

Gambar 15 Presentase Hasil Kuesioner Gambar 16 Presentase Hasil Kuesioner

Kategori Kegunaan Sistem Kategori Kualitas Informasi

  

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.