Institutional Repository | Satya Wacana Christian University: Perancangan Modul Korwil Menggunakan Platform PEGA System di PT. Asuransi Sinarmas Jakarta

Perancangan Modul Korwil Menggunakan

  Platform PEGA System di PT. Asuransi Sinarmas Jakarta Artikel Ilmiah Peneliti: Edwin Oknellius Budianto(672014005) Magdalena A. Ineke Pakereng, M.Kom. Program Studi Teknik Informatika Fakultas Teknologi Informasi Universitas Kristen Satya Wacana Salatiga September 2017

  1. Pendahuluan

  Pada zaman teknologi yang terus berkembang pesat, setiap tahunnya selalu ada perkembangan dalam bidang platform dan tolls yang memudahkan developer untuk mengembangkan aplikasi, dan juga membantu user untuk menggunakan aplikasi yang telah dikembangkan. Oleh karena hal tersebut, setiap perusahaan berusaha untuk menggunakan

  

platform yang dapat memudahkan dalam mengelola Business Process Management (BPM).

Business Process Management (BPM) adalah sebuah pendekatan dalam menggabungkan

  pengetahuan dari teknologi informasi dan pegetahuan dari manajemen dan menerapkannya pada operasional proses bisnis [1]. BPM mendapatkan banyak perhatian dalam beberapa tahun terakhir, karena potensinya dalam meningkatkan secara signifikan produktivias dan mengurangi biaya pengeluaran [2]. Kemampuan BPM bisa digunakan untuk menjadi perantara antara komunitas bisnis dan sistem TI dengan cara menjalankan operasi bisnis, membuat sistem lebih lincah dan responsif terhadap perubahan kebutuhan bisnis, meningkatkan visibilitas operasional yang memungkinkan tata kelola dan control yang lebih baik, dan membuka jalan menuju tingkat bisnis yang lebih luas dan lebih dalam [3].

  Salah satu perusahaan yang memanfaatkan perkembangan teknologi yang cepat ini adalah PT. Asuransi Sinar Mas, yang sedang mengkonversi aplikasi program asuransi dari

  

platform ASP Classic ke platform PEGA System. Platform PEGA System dipilih oleh

  perusahaan PT Asuransi Sinar Mas, karena PEGA System merupakan platform yang berfokus pada proses pengambilan keputusan yang sering ditemukan di industri-industri seperti layanan keuangan, asuransi, dan industri yang mengkhususkan dalam memberikan solusi dalam proses untuk kebutuhan proses tertentu [4]. Aplikasi yang menggunakan

  

platform ASP Classic memiliki kekuragan yaitu mempersulit user dalam tracking sparepart

  yang di-order, membutuhkan waktu yang cukup lama dalam pencarian supplier dan

  

platform ASP Classic tidak bisa membuat business flow yang diperlukan atau menciptakan

business flow yang diinginkan PT Asuransi Sinar Mas. Salah satu jenis asuransi yang

  terdapat di PT Asuransi Sinar Mas adalah Asuransi kendaraan yang di dalamnya terdapat proses klaim mbu. Proses klaim mbu juga dibagi dalam beberapa modul, dimana setiap modul memiliki fungsi yang saling mendukung dalam proses klaim.

  Berdasarkan latar belakang masalah maka dilakukan penelitian yang bertujuan untuk merancang modul korwil yang digunakan untuk memproses dan memberi keputusan kepada panel-panel tambahan selain panel yang telah disurvei oleh surveyor. Adapun manfaat dari penelitian ini adalah untuk menghasilkan modul korwil yang akan digunakan untuk membantu dalam proses klaim mbu kendaraan bermotor.

  2. Tinjauan Pustaka

  Penelitian pertama yang dapat digunakan sebagai pembanding dalam penelitian ini adalah 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 tersebut adalah waktu yang dapat dipersingkat dengan menggunakan aplikasi yang baru adalah 26,28 detik dan peningkatan kinerja sebsesar 53%, serta dapat menghemat pengeluaran biaya perusahaan sebesar $4800 [6].

  Berdasarkan penelitian-penelitian terdahulu tentang perancangan aplikasi menggunakan platform PEGA System, maka dilakukan penelitian tentang perancangan modul korwil untuk mendukung dalam pengambilan keputusan pada panel-panel tambahan dalam proses klaim mbu kendaraan bermotor dengan menggunakan platform PEGA System. Berbeda dengan Modul Korwil yang sebelumnya yang mengelola proses beberapa panel dalam 1 proses, modul Korwil baru yang dirancang memproses hanya 1 panel saja dalam 1 proses. Sehingga dalam proses tracking sparepart yang dilakukan oleh user dapat lebih jelas dan teliti.

  Terdapat tiga software yang sering digunakan untuk mengelola BPM dari sebuah perusahaan yaitu PEGA System, IBM, dan TIBCO. Analisis dari tiga software berdasarkan waktu yang dapat dipersingkat pada project tertentu, solusi yang didapat berdasarkan resikonya dan nilai potensinya ditunjukkan pada Tabel 1 [3].

  

Tabel 1 Perbandingan PEGA System, IBM, TIBCO Software [3]

Time to value Risk Value potential

• ve +ve -ve +ve -ve +ve _{■■■■■■■■■□ ■■■■■■■■■□ ■■■■■□□□□□} Pegasystems _{■■■■■■■■□□ ■■■■■■■■□□ ■■■■■■■■■□}

  IBM _{■■■■■■■□□□ ■■■■■■□□□□ ■■■□□□□□□□} TIBCO Software

  Tabel 1 menunjukkan bahwa PEGA System memiliki Time to Value dan Risk yang lebih baik dibandingkan dari IBM dan TIBCO Software. Dalam hal nilai potensinya PEGA System memiliki nilai yang lebih baik dari TIBCO Software tetapi nilainya masih di bawah IBM.

  

PEGA System menawarkan solusi spesifik untuk tujuan industri atau perusahaan yang

  dibangun dan PEGA System memiliki PRPC yang dapat meningkatkan pengalaman dari

  

developer dan user, dengan cara developer dan user mengetahui secara langsung tampilan

  dari aplikasi, keamanan, flexible data reuse, kemampuan sosial dan peningkatan konektivitas aplikasi dalam hal kepuasan pelanggan [7]. Sehingga PEGA system cocok digunakan dalam bidang asuransi, karena asuransi merupakan hal yang selalu berkembang.

  PEGA System telah menyediakan 2 jenis metodologi implementasi: 1). SmartBPM

Methodology, 2). PEGA Scrum. Metodologi yang digunakan adalah SmartBPM

Methodology, karena merupakan metodologi yang mendukung dalam proses perancangan

  modul korwil, hal tersebut dikarenakan modul korwil merupakan bagian kecil dari project untuk simas mobil. Hampir sama dengan Rational Unified Process (RUP), pada SmartBPM mempunyai pendekatan secara iteratif dalam pengembangan, dan terdiri dari 4 tahap dan 2

  

activity tambahan. Metodologi SmartBPM lebih berfokus pada fleksibilitas sehingga project

yang dikerjakan bisa dibagi menjadi beberapa project kecil [8].

  Project dipecah menjadi beberapa project sehingga dapat mempercepat fungsi dari aplikasi yang telah di-release tanpa menggangu proses dan data yang telah di- input [9].

  

Gambar 1 Proses SmartBPM Methodology

  Gambar 1 menunjukkan proses pada SmartBPM Methodology, dijelaskan sebagai berikut:

• Project Initiation Activity, tahap ini adalah persiapan untuk pembuatan project untuk mendapatkan data yang diperlukan, atau disebut requirements gathering.
• Inception Phase, tahap ini adalah tahap dimana developer mengumpulkan business

  requirements dan membuatnya menjadi sebuah project. Project yang telah dibuat akan dipecah-pecah lagi menjadi beberapa bagian kecil, bagian kecil ini disebut dengan slivers.

• Elaboration Phase, pada tahap ini slivers yang telah dibuat akan didetailkan lagi, dan selanjutnya diteruskan dengan pembuatan work flow dan UI design.
• Construction Phase, tahap ini data akan diimplementasikan ke dalam slivers dan juga membuat beberapa program yang diperlukan yang biasanya berupa program untuk validasi data dan pengolahan data.
• Transition Phase, tahap ini adalah tahap dimana aplikasi yang telah dibuat akan diuji.

  Tahap ini berfokus kepada end to end testing dan user acceptance untuk menjamin kematangan dari aplikasi tersebut.

• Go-Live Activity, tahap dimana slivers yang telah jadi akan di-release dan digunakan oleh user.

  Secara umum penelitian terbagi ke dalam empat tahap, yaitu: (1) tahap identifikasi masalah, (2) perancangan modul, (3) implementasi modul, (4) pengujian modul.

  Identifikasi Masalah Perancangan Modul Implementasi Modul Pengujian Modul Gambar 2 menunjukkan tahapan jalannya penelitian yang dijelaskan sebagai berikut. Langkah 1 : Identifikasi Masalah dengan cara menguraikan dan menjelaskan masalah yang diambil kemudian merumuskan masalah tersebut ke dalam batasan masalah. Batasan masalah yang diambil dalam perancangan modul korwil menggunakan PEGA System, yaitu: jumlah panel yang diproses pada modul korwil hanya satu saja. Modul-modul lain yang berhubungan dengan modul korwil adalah modul kabas dan modul bengkel. Langkah 2 : Perancangan Modul Korwil dengan cara merancang dulu stage dan step-step yang akan digunakan untuk modul korwil. Kemudian dalam step-step terdapat flow action yang berisi section dan activity untuk jalannya proses modul korwil. Langkah 3 : Implementasi Modul Korwil dengan cara mengimplementasikan sistem modul korwil yang menggunakan ASP ke PEGA System, dan juga flow chart yang telah ada sebelumnya pada flow PEGA. Pada flow Pega terdapat flow

action yang memungkinkan user dapat berpindah dari satu flow ke flow yang lainnya.

  Langkah 4 : Pengujian Modul dilakukan setelah modul jadi oleh user yang akan menggunakan modul korwil atau oleh supervisor IT bagian klaim MBU.

  Perancangan proses pada modul korwil 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 [10]. Use case diagram sistem ditunjukkan pada Gambar 3. _{Pilih Jenis Perawatan <<include>> Update Progress Update Nama Bengkel <<include>> Update Wilayah Bengkel <<include>> <<include>>}

  Hapus Panel <<include>> _{Melakukan Pengajuan Kelola Panel <<include>> <<extend>> <<include>> <<include>> Memutuskan Pindah Bengkel Memberi Keputusan pada Panel <<extend>> User Korwil User Bengkel <<include>>}

_{Input Tanggal Perbaikan <<include>>}

_{<<include>> <<include>> Menerima Pengajuan Melakukan Banding} <<extend>> _{<<extend>> Update Harga Input Alasan} Input Janji Selesai _{Input Tanggal Masuk User Kabas}

Gambar 3 Use Case Diagram Modul

  Gambar 3 menunjukkan use case diagram yang akan digunakan pada modul. User pada sistem dibagi atas 3 yakni bengkel, korwil dan kabas. User bengkel adalah user yang bertugas untuk mengelola panel dan input tanggal perbaikan. User korwil adalah user yang memiliki wewenang untuk memberi keputusan pada panel dan apakah panel pindah bengkel atau tidak.

  

User kabas adalah user yang menerima pengajuan dari user bengkel dan dapat melakukan

banding ke user korwil.

  _{Pilih Panel} User Bengkel User Korw il _{Perawatan Panel} Pilih Jenis Review _{Persetujuan Proses Tidak Setuju Update Satus Progress Reques Update}

Setuju

Gambar 4 Activity Diagram Proses Pengajuan Panel

  Gambar 4 menunjukkan activity diagram untuk proses pengajuan panel. Pertama, user bengkel memilih panel dan jenis perawatan dari panel tersebut. Kemudian panel tersebut akan di-review oleh user korwil dan melalui proses persetujuan, korwil akan menentukan apakah setuju dengan pengajuan panel atau tidak. Jika setuju akan update status request dan kemudian update progress, jika tidak user bengkel dapat memilih lagi panel. _{User Korw il User Kabas Persetujuan} Review _{Panel Proses Update Satus Request Setuju} Tidak Setuju _{Menampilkan Review Panel Melakukan Banding} Tidak Banding _Banding

  

Gambar 5 Activity Diagram Proses Banding Kabas

  Gambar 5 menunjukkan activity diagram untuk proses banding kabas. Pertama, user korwil melakukan review panel, kemudian melakukan proses persetujan. Jika setuju update

  

status request, jika tidak akan menampilkan review panel pada user kabas. Kabas memiliki

  pilihan untuk melakukan banding atau tidak. Jika melakukan banding akan menampilkan review panel lagi pada user korwil.

  

Gambar 6 Class Diagram Klaim Antara Modul Bengkel dan Modul Korwil

  Gambar 6 merupakan Class diagram yang digunakan oleh sistem. Setiap class pada Gambar 6 menunjukkan setiap komponen yang dibutuhkan pada sistem yang mana class-

  

class tersebut akan dijadikan sebagai acuan pembuatan Tabel pada database sistem. Sistem

  menggunakan relasi one-to-many antar class. Setiap derajat relasi one pada diagram class akan digunakan sebagai primary key pada Tabel dan setiap derajat relasi many pada diagram akan digunakan sebagai foreign key pada Tabel yang akan dibuat.

  Pembuatan Flow Modul Korwil, dijelaskan sebagai berikut Flow adalah dasar dari .

  

PEGA System, karena PEGA System adalah sebuah sistem yang berbasis proses. Jadi untuk

  memulai membuat sebuah sistem di dalam PEGA System, membutuhkan sebuah proses yang sudah tertata dari awal sampai akhir. Case adalah flow yang berisi smart shape. Pada case bengkel, setiap panel memiliki 3 pilihan yaitu nego harga, permintaan ganti, dan setuju. Jika

  

user memilih setuju dengan harga perbaikan pada panel maka bengkel akan setuju dengan

  permintaan perbaikan pada panel tersebut. Tetapi jika user memilih nego harga dan permintaan ganti, bengkel harus menunggu persetujuan dari korwil dan bengkel akan membuat case ke korwil tentang permintaan untuk ganti panel dan nego harga pada panel tersebut. Setelah mengisi data pada case ganti panel atau nego harga, korwil akan membuat

  

case pada kabas. Case yang terbuat pada kabas adalah case banding kabas dan case kabas

  banding harga. Agar tidak terjadi kebingungan pada korwil dan untuk mengetahui pilihan yang di-input-kan user pada panel apakah itu nego harga, permintaan ganti, atau setuju, maka saat user memilih akan di-set flag condition. Jika flag condition-nya 1 berarti pilihan panel yang dipilih adalah nego harga sedangkan untuk flag condition 2 berarti pilihan panel yang dipilih adalah permintaan ganti. Untuk pilihan panel setuju, tidak di-set flag condition, karena bengkel tidak membuat case pada korwil dan bengkel akan membuat case pada premium

  

repair sebab bengkel sudah setuju dengan kondisi panel tersebut. Flow korwil untuk nego

  

Gambar 7 Proses Modul Korwil (Price Negotiation & Request Replace)

Case kabas banding adalah case yang terbuat dari case request replace, sedangkan case

  kabas banding harga adalah case yang terbuat dari case price negotiation. Pada case kabas ini

  

user harus meng-input-kan alasan kenapa kabas melakukan banding kepada korwil. Saat

  selesai meng-input-kan alasan, kabas juga akan membuat case ke korwil, dan yang terbuat pada korwil adalah from kabas banding dan from kabas banding harga. Pada saat kabas melakukan banding, kabas juga akan men-set flag condition. Flag condition 4 jika dari kabas banding dan flag condition 5 jika dari Kabas Banding Harga. Biasanya sebelum kabas melakukan banding pihak kabas akan melakukan perundingan di belakang sistem dengan pihak bengkel tentang kondisi dari panel yang dikerjakan oleh bengkel. Flow Kabas untuk kabas banding dan kabas banding harga ditunjukkan pada Gambar 8.

  

Gambar 8 Proses Modul Kabas (Kabas Banding & Kabas Banding Harga)

Case From kabas banding adalah case yang terbuat dari case kabas banding, sedangkan

case from kabas banding harga adalah case yang terbuat dari case kabas banding harga. Pada

case korwil ini adalah keputusan akhir dari korwil apakah korwil menyetujui dengan

  permintaan banding dari kabas atau tidak setuju. Flow korwil from kabas banding dan from kabas banding harga ditunjukkan pada Gambar 9.

  

Gambar 9 Proses Modul Korwil (From Kabas Banding & From Kabas Banding Harga)

  Pembuatan section modul korwil, dijelaskan sebagai berikut. Pada smart shape

  

assignment atau connector yang ada pada case biasanya memiliki flow action. Pada flow

action tersebut terdapat section dan activity yang digunakan untuk memproses flow action

  tersebut. Section merupakan tampilan atau user interface yang ada pada PEGA System. Tampilan pada Flow action dari connector pirce negotiation ditunjukkan pada Gambar 10.

  

Gambar 10 Flow Action dari Connector Price Negotiation

Section adalah tampilan antar muka untuk pengguna atau sering disebut user interface.

  Pembuatan section pada setiap flow action harus disesuaikan dengan kebutuhan user. Untuk membuat tampilan user interface sesuai yang dinginkan, section biasanya diisi oleh 3 komponen utama yaitu layout, basic, dan advanced. Layout yang sering digunakan adalah

  

dynamic layout dan grid repeat layout. Pada basic terdapat pilihan button, drop down, radio

button dan lain-lainya. Dalam section juga dapat memanggil section lain dari kelas yang

  berbeda. Tampilan pada section review price negotiation ditunjukkan pada Gambar 11.

  

Gambar 11 Section Review Price Negotiation

  Pembuatan activity modul korwil, dijelaskan sebagai berikut. Activity merupakan sebuah fungsi yang dibuat dari step-step yang harus disusun secara terstruktur, karena activity akan dijalankan dari step yang paling pertama sampai dengan yang terakhir. Setiap step dalam activity mempunyai fungsi masing-masing. Dalam step-step tersebut ada beberapa bagian, yang pertama adalah label. Label dapat digunakan sebagai lompatan ke step lain (sebagai contoh jika dari step 1 kemudian akan langsung ke step 8), untuk melakukan hal itu

  

label dari step yang dituju harus dinamai terlebih dahulu. Label juga memiliki fungsi bisa

  digunakan agar step tidak dijalankan, selain itu setiap step mempunyai fungsi loop dan fungsi when. Fungsi loop digunakan untuk melakukan looping pada data yang berbentuk list. Fungsi when digunakan untuk memberikan kondisi yang harus dipenuhi sebelum step tersebut dijalankan. Setelah itu ada method, dimana method memiliki fungsi-fungsi yang telah disediakan oleh PEGA. Method yang digunakan pada Gambar 12 adalah Page-New, Property-Set, Obj-Open-By-Handle, Obj-Save, Commit dan juga Page-copy.

  Method Page-New digunakan untuk membuat halaman baru pada kelas yang diinginkan.

Method Property-set digunakan untuk set value pada property kelas tersebut maupun kelas

  lain. Method Obj-Open-By-Handle digunakan untuk membuka dan meng-edit kelas yang dituju. Method Obj-Save digunakan untuk menyimpan apa yang sudah di-set pada kelas tersebut. Kemudian Commit untuk menyimpan perubahan data pada flow. Serta method page- copy digunakan untuk meng-copy satu page ke page lainnya.

  Komponen terakhir pada activity adalah description. Description digunakan untuk memberikan deskripsi tentang apa yang dilakukan pada step tersebut, sehingga jika ada orang lain yang ingin meng-edit atau mempelajari activity tersebut akan lebih mudah, karena telah ada penjelasan tentang step tersebut.

  Pada activity juga terdapat Page and Clasess yang digunakan untuk menamai page dan dari mana kelas yang dituju oleh page tersebut. Activity pada flow price negotiation Korwil ditunjukkan pada Gambar 12.

  

Gambar 12 Activity Flow Price Negotiation Korwil

  Sebelum bisa memilih opsi pada panel, panel pada bengkel terlebih dahulu harus mendapatkan persetujuan dari kabas. Setelah kabas menyetujui permintaan dari bengkel barulah bengkel bisa memilih opsi dari panel tersebut. Tampilan pada case bengkel ditunjukkan pada Gambar 13 dan Gambar 14.

  

Gambar 13 Tampilan Case Bengkel (Bagian 1)

Gambar 14 Tampilan Case Bengkel (Bagian 2) korwil. Kemudian korwil akan meng-update keterangan ke bengkel (korwil tidak setuju dengan permintaan ganti) dan akan membuat case pada kabas yaitu case kabas banding, selain itu pada case permintaan ganti ini user dapat melihat detail polis dan melihat detail clm polis dari panel tersebut. Tampilan pada case Permintaan Ganti pada korwil ditunjukkan pada Gambar 15 dan Gambar 16.

  

Gambar 15 Tampilan Case Permintaan Ganti Jika Korwil Setuju

Gambar 16 Tampilan Case Permintaan Ganti Jika Korwil Tidak Setuju

  Pada case kabas banding, kabas dapat melihat alasan dari korwil dan kabas harus meng-input-kan alasan dari kabas jika ingin melakukan banding ke korwil. Saat melakukan banding kabas, kabas akan meng-update keterangan pada bengkel (Kabas sedang mengajukan banding ke korwil) dan membuat case ke korwil. Tampilan pada case kabas banding ditunjukkan pada Gambar 17.

  

Gambar 17 Tampilan Case Kabas Banding

  Pada case from kabas banding, korwil dapat melihat alasan awal dari korwil dan alasan dari kabas banding. Pada case ini korwil juga memiliki wewenang untuk menyetujui ataupun menolak permintaan ganti pada panel yang telah dibanding oleh kabas. Jika korwil setuju, korwil akan membuat case ke qu. Saat korwil tidak setuju, korwil akan meng-update keterangan ke bengkel (korwil tidak setuju dengan permintaan ganti) dan bengkel hanya bisa melakukan nego harga karena permintaan ganti telah ditolak oleh korwil. Tampilan pada case

  from kabas banding ditunjukkan pada Gambar 18.

  

Gambar 18 Tampilan Case From Kabas Banding

  Pada case Price Negotiation, korwil dapat melihat harga yang diajukan oleh bengkel pada history harga. Korwil dapat meng-edit lagi harga yang ada pada case. Jika setuju, harga yang telah ada tidak perlu di-edit, dan jika korwil menolak, maka harus meng-input-kan harga baru. Pada case ini korwil juga memiliki wewenang untuk memutuskan apakah menerima nego harga dari bengkel atau tidak. Saat korwil setuju maka akan meng-update keterangan pada bengkel (harga disetujui oleh korwil). Apabila tidak diterima, korwil akan meng-update keterangan pada bengkel (harga tidak disetujui oleh korwil) dan akan membuat

  

case pada kabas banding harga. Tampilan pada case price negotiation ditunjukkan pada

Gambar 19.

  

Negotiation (Jika Korwil Setuju)

  Pada case Kabas Banding Harga, kabas dapat melihat harga yang diajukan oleh bengkel dan korwil pada history harga. Kabas harus meng-edit lagi harga yang ada pada case ini dan harus mengisi alasan kabas jika ingin melakukan banding ke kabas. Saat kabas melakukan banding, kabas meng-update keterangan pada bengkel (Kabas melakukan banding ke korwil) dan membuat case pada korwil yaitu from kabas banding harga. Tampilan pada case kabas banding harga ditunjukkan pada Gambar 20.

  

Gambar 20 Tampilan Case Kabas Banding Harga

  Pada case from kabas banding harga, korwil dapat melihat harga yang diajukan oleh bengkel, korwil saat di-case price negotiation dan harga yang diajukan oleh kabas banding harga pada history harga. Korwil dapat meng-edit lagi harga yang ada pada case. Jika setuju, harga yang telah ada tidak perlu di-edit, jika korwil menolak harus meng-input-kan harga baru. Pada case ini, korwil memiliki wewenang untuk memutuskan apakah menerima banding dari kabas atau tidak. Jika korwil setuju, maka akan meng-update keterangan pada bengkel (harga disetujui oleh korwil). Tetapi jika tidak diterima korwil, akan meng-update keterangan pada bengkel (harga tidak disetujui oleh korwil). Tampilan pada case from kabas banding harga ditunjukkan pada Gambar 21.

  Perbedaan antara korwil lama dan korwil baru yang telah dirancang, akan dijelaskan pada Tabel 2.

  blackbox testing ditampilkan pada Tabel 3.

  detail clm sebelumnya, dan detail polis Sesuai yang diharapkan.

  User dapat melihat detail clm,

  3 User dapat melihat data klaim sebelumnya

  tidak setuju, serta meng-input alasan Sesuai yang diharapkan.

  User dapat memilih setuju dan

  2 User dapat menentukan pilihan dan input alasan

  Sesuai yang diharapkan.

  surveyor.

  Data yang ditampilkan sesuai dengan data dari bengkel dan

  1 User me-review data panel.

  

Tabel 3 Hasil Blackbox Testing

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

  

Tabel 2 Perbandingan Korwil Lama dan Korwil Baru

  

testing. Blackbox Testing dilakukan untuk mengetahui bahwa semua fungsi dan fitur pada

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

  Berdasarkan Tabel 2, disimpulkan bahwa terdapat 4 point yang menjadi perbedaan antara korwil lama dan korwil baru yaitu jumlah panel dan wo, pindah bengkel, nego harga, dan meta data.

  Pengecekan meta data gambar dapat dilakukan di case

  4 Meta data Pengecekan meta data gambar dilakukan melalui aplikasi lain

  Nego harga dilakukan melalui case

  3 Nego harga Nego harga dilakukan melalui email

  Panel terdapat pilihan unutk pindah bengkel

  2 Pindah bengkel Panel tidak ada pilihan untuk pindah bengkel

  1 WO memiliki banyak panel

  1 Jumlah panel dan wo 1 panel memiliki banyak WO

  No Perbedaan Korwil Lama Korwil Baru

No Deskripsi Hasil yang Diharapkan Hasil yang Diberikan Modul

  Modul Korwil dapat Modul Korwil dapat membuat Sesuai yang membuat case ke case ke kabas, jika korwil tidak diharapkan. 5 kabas setuju

  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

  Internet

  V

  1 Explorer

  2. Mozilla Firefox

  V 3.

  V Chrome 4.

  V Safari

  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 14 pertanyaan yang dibagi dalam 3 kategori pertanyaan yaitu 4 pertanyaan untuk kategori Kegunaan Sistem/System Usability (SYSUSE), 6 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 oleh peneliti [11]. 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-fungsi yang ada pada modul

  2 Penggunaan modul ini cukup sederhana.

  3 Saya dapat menyelesaikan pekerjaan dengan menggunakan modul ini.

  4 Mudah untuk belajar menggunakan modul ini. bagaimana untuk memperbaiki masalah.

  6 Setiap kali saya membuat kesalahan saat menggunakan modul, saya memperbaikinya dengan mudah dan cepat.

  7 Informasi (seperti lihat detail klaim, lihat klaim sebelumnya, lihat detail polis ) yang disediakan dengan modul ini mudah dimengerti.

  8 Mudah untuk menemukan informasi yang saya butuhkan.

  9 Informasi yang disediakan untuk modul ini mudah dimengerti.

  10 Informasi yang disediakan, efektif dalam membantu saya menyelesaikan tugas-tugas.

Kualitas Antarmuka/Interface Quality (INTERQUAL) 11 Pengaturan informasi pada tampilan modul jelas

  12 Antarmuka (tampilan) dari sistem ini nyaman dilihat.

  13 Modul ini memiliki semua fungsi diharapkan.

  14 Secara keseluruhan, saya puas dengan modul ini.

  Kuesioner ditujukan kepada staff karyawan IT PT. Asuransi Sinarmas yang berjumlah 4 responden dengan rincian 1 project leader, 1 staf operational dan 2 programmer (modul bengkel dan modul kabas). Hasil kuesioner diolah menjadi hasil pengujian yang ditampilkan pada Gambar 22, Gambar 23 dan Gambar 24.

  Gambar 22 Prosentase Hasil Kuesioner Kategori Kegunaan Sistem

  Gambar 23 Prosentase Hasil Kuesioner Kategori Kualitas Informasi

  

Gambar 24 Prosentase Hasil Kuesioner

Kategori Kualitas Antarmuka

  Berdasarkan hasil usability testing pada Tabel 5 disimpulkan bahwa, untuk kategori Kegunaan Sistem, 75% responen memberi nilai 2, yang berarti bahwa modul sudah cukup baik. Untuk kategori Kualitas Informasi, 62.5% responen memberi nilai 2, modul memberikan informasi dengan cukup baik. Untuk kategori Kualitas Antarmuka, 56.25% responden memberi nilai 2, yang berarti sistem memiliki desain antarmuka yang agak kurang.

  Secara keseluruhan berarti semua responden berpendapat bahwa sistem yang dibuat sudah dapat memenuhi kebutuhan user.

  5. Simpulan

  Berdasarkan hasil dan pembahasan yang dilakukan tentang, perancangan modul korwil menggunakan platform PEGA System, maka dapat diambil kesimpulan sebagai berikut: (1) flow, flow action, section, dan activity merupakan bagian-bagian yang terpenting dalam pembuatan modul korwil; (2) Modul korwil sudah dapat digunakan untuk memproses dan memberi keputusan kepada panel-panel tambahan selain panel yang telah disurvei oleh

  

surveyor yang berada di bengkel. Saran yang diberikan untuk pengembangan ke depannya

  adalah Tampilan dari modul dibuat lebih user friendly dan terdapat user manual sehingga user dapat menggunakan modul dengan lebih mudah.

  6. Daftar Pustaka

  [1] Weske, M. Bussiness Process Management: Concepts, Languages, Architectures, Springer-Verlag, Berlin, Germany, 2007. [2] Weske, M. Business process management a survey in, Proceedings of the International

  Conference on Business ProcessManagement (BPM’03), vol. 2678 of Lecture Notes in Computer Science, pp. 1–12.Sugianto, E. 2013.

  [3] Craggs, S. (2011). Comparing BPM from Pegasystems, IBM and TIBCO. https://pdfs.semanticscholar.org.pdf, Diakses 17 September 2017.

  [6] Dandavathi, S. K. (2016, Agustus). Building an Aplication for the Automation of

  Onboarding of an Employee, Department of Mechanical and Manufacuring Engineering, Paper 58.

  [7] Yeddula, J. C. R. (2015, Desember). Improving Performance of Customer Succes

  Centre using PRPC, Department of Mechanical and Manufacuring Engineering, Paper 25.

  [8] Chellar, D. (2012). Getting Started with SMartBPM. 17 September 2017. [9] PEGAPDN (2017). Implementation Methodology Overview. Diambil 17 Spetember

  2017, dari https://pdn.pega.com/implementation-methodology- overview/implementation-methodology-overview. [10] Pressman, R. S. 2012. Rekayasa Perangkat Lunak. Yogyakarta: Andi. [11] Ridwan, Akdon. 2008. Rumus dan Data dalam Analisis Statistika. Bandung: Alfabeta.