RANCANG BANGUN APLIKASI PENANGANAN KOMPLAIN
MENGGUNAKAN ADMINISTRATIVE WORKFLOW SYSTEM PADA
PT PETROKIMIA GRESIK
TUGAS AKHIR
Program Studi
S1 Sistem Informasi
Oleh:
AFIFUDDIN MUHAJIR
10.41010.0135
FAKULTAS TEKNOLOGI DAN INFORMATIKA
i
Halaman
ABSTRAK ... vi
KATA PENGANTAR ... vii
DAFTAR ISI ... ix
DAFTAR TABEL ... xii
DAFTAR GAMBAR ... xv
DAFTAR LAMPIRAN ... xix
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 4
1.3 Pembatasan Masalah ... 5
1.4 Tujuan Penelitian ... 5
1.5 Manfaat Penelitian ... 5
1.6 Sistematika Penulisan ... 6
BAB II LANDASAN TEORI ... 8
2.1 Manajemen Komplain ... 8
2.2 Workflow Management System ... 11
2.2.1 Elemen Kerja Kunci dalam Workflow System ... 11
2.2.2 Administrative Workflow System ... 14
2.3 Perangkat Lunak (Software) ... 14
2.4 Perangkat Keras (Hardware) ... 16
2.5 Web ... 16
ii
2.7.1 White Box Testing ... 21
2.7.2 Black Box Testing ... 22
2.8 Skala Likert ... 22
BAB III ANALISIS DAN PERANCANGAN SISTEM ... 24
3.1 Analisis Sistem ... 24
3.1.1 Komunikasi ... 24
3.1.2 Perencanaan ... 39
3.2 Perancangan Sistem ... 39
3.2.1 Perancangan Arsitektur Sistem ... 40
3.2.2 Perancangan Proses ... 41
3.2.3 Perancangan Basis Data ... 57
3.2.4 Perancangan Antar Muka ... 69
3.3 Perancangan Pengujian Sistem ... 82
3.3.1 Pengujian Sistem Oleh Ahli Sistem ... 82
3.3.2 Pengujian Sistem Oleh Pengguna ... 88
BAB IV IMPLEMENTASI DAN EVALUASI ... 91
4.1 Implementasi Sistem (Konstruksi Sistem) ... 91
4.1.1 Kebutuhan Sistem ... 91
4.1.2 Hasil Implementasi Sistem ... 92
4.2 Evaluasi Sistem (Pengujian Sistem) ... 105
4.2.1 Hasil Uji Coba ... 106
iii
5.1 Kesimpulan ... 139
5.2 Saran ... 140
DAFTAR PUSTAKA ... 141
iv
Tabel 2.1 Keterangan Nilai Skala Likert ... 23
Tabel 3.1 Kebutuhan Pengguna Unit Eksternal ... 28
Tabel 3.2 Kebutuhan Pengguna Kepala Bagian ... 29
Tabel 3.3 Kebutuhan Pengguna Tim Perbaikan ... 29
Tabel 3.4 Fungsi Pengajuan Komplain ... 32
Tabel 3.5 Fungsi Pendelegasian ... 33
Tabel 3.6 Fungsi Pencatatan Kerusakan ... 34
Tabel 3.7 Fungsi Penggantian Produk Hardware/Software ... 35
Tabel 3.8 Fungsi Penggantian Produk Komponen/Form ... 36
Tabel 3.9 Fungsi Perbaharui Perkembangan ... 37
Tabel 3.10 Fungsi Penyelesaian ... 38
Tabel 3.11 Struktur Tabel Tim ... 59
Tabel 3.12 Struktur Tabel Detil Tim ... 63
Tabel 3.13 Struktur Tabel Hardware ... 63
Tabel 3.14 Struktur Tabel Software ... 64
Tabel 3.15 Struktur Tabel Komponen ... 64
Tabel 3.16 Struktur Tabel Form ... 65
Tabel 3.17 Struktur Tabel Komplain ... 65
Tabel 3.18 Struktur Tabel Komplain_Hard ... 66
Tabel 3.19 Struktur Tabel Komplain_Soft ... 66
Tabel 3.20 Struktur Tabel Prog_Form ... 67
v
Tabel 3.23 Struktur Tabel Pegawai ... 68
Tabel 3.24 Struktur Tabel Bagian ... 68
Tabel 3.25 Struktur Tabel Departemen ... 69
Tabel 3.26 Uji Coba Halaman Login ... 83
Tabel 3.27 Uji Coba Halaman Pengajuan Komplain ... 84
Tabel 3.28 Uji Coba Halaman Pendelegasian ... 84
Tabel 3.29 Uji Coba Halaman Pencatatan Kerusakan ... 85
Tabel 3.30 Uji Coba Halaman Penggantian Produk ... 86
Tabel 3.31 Uji Coba Halaman Perkembangan Komplain ... 87
Tabel 3.32 Uji Coba Halaman Penyelesaian Komplain ... 87
Tabel 3.33 Uji Coba Angket Unit Eksternal ... 88
Tabel 3.34 Uji Coba Angket Kepala Bagian ... 89
Tabel 3.35 Uji Coba Angket Tim Perbaikan ... 89
Tabel 3.36 Uji Coba Angket Manajer ... 89
Tabel 3.37 Uji Coba Angket Ahli Sistem ... 90
Tabel 4.1 Hasil Uji Coba Login ... 107
Tabel 4.2 Hasil Uji Coba Pengajuan Komplain ... 109
Tabel 4.3 Hasil Uji Coba Pendelegasian ... 112
Tabel 4.4 Hasil Uji Coba Pencatatan Kerusakan ... 115
Tabel 4.5 Hasil Uji Coba Penggantian Produk ... 118
Tabel 4.6 Hasil Uji Coba Perkembangan Komplain ... 120
vi
Tabel 4.9 Hasil Uji Coba Pengguna Kepala Bagian ... 129
Tabel 4.10 Hasil Uji Coba Pengguna Tim ... 131
Tabel 4.11 Hasil Uji Ahli Sistem ... 132
vii
Gambar 2.1 Elemen Kerja Kunci dalam Workflow System ... 12
Gambar 2.2 Model Waterfall... 18
Gambar 3.1 Arsitektur Sistem ... 41
Gambar 3.2 Context Diagram ... 44
Gambar 3.3 Diagram Berjenjang ... 48
Gambar 3.4 DFD Level 0 ... 49
Gambar 3.5 DFD Level 1 Proses Pengajuan Komplain ... 51
Gambar 3.6 DFD Level 1 Proses Pendelegasian Komplain ... 51
Gambar 3.7 DFD Level 1 Proses Pencatatan Kerusakan ... 52
Gambar 3.8 DFD Level 1 Proses Penggantian Produk ... 53
Gambar 3.9 DFD Level 1 Proses Perkembangan Komplain ... 54
Gambar 3.10 DFD Level 1 Proses Penyelesaian Komplain ... 55
Gambar 3.11 DFD Level 2 Proses Penggantian Hardware/Software ... 56
Gambar 3.11 DFD Level 2 Proses Penggantian Komponen/Form ... 57
Gambar 3.12 Entity Relationship Diagram (ERD) ... 60
Gambar 3.13 Conceptual Data Model (CDM) ... 61
Gambar 3.14 Physical Data Model (PDM) ... 62
Gambar 3.15 Rancangan Input Perbaikan... 70
Gambar 3.16 Rancangan Output Laporan Data Komplain ... 71
Gambar 3.17 Rancangan Halaman Login ... 72
Gambar 3.18 Rancangan Halaman Pengajuan Komplain ... 73
viii
Gambar 3.21 Rancangan Halaman Penggantian Hardware ... 76
Gambar 3.22 Rancangan Halaman Penggantian Software... 77
Gambar 3.23 Rancangan Halaman Penggantian Komponen ... 78
Gambar 3.24 Rancangan Halaman Penggantian Form ... 79
Gambar 3.25 Rancangan Halaman Perkembangan ... 79
Gambar 3.26 Rancangan Halaman Penyelesaian Komplain ... 80
Gambar 3.27 Rancangan Halaman Tim ... 81
Gambar 3.28 Rancangan Halaman Detil Anggota Tim ... 82
Gambar 4.1 Halaman Login ... 93
Gambar 4.2 Halaman Menu Unit Eksternal ... 95
Gambar 4.3 Halaman Menu Kepala Bagian ... 95
Gambar 4.4 Halaman Menu TIM Perbaikan Produk ... 96
Gambar 4.5 Halaman Pengajuan Komplain ... 97
Gambar 4.6 Halaman Pendelegasian Komplain ... 98
Gambar 4.7 Halaman Detil Pendelegasian Komplain ... 99
Gambar 4.8 Halaman Perbaikan Komplain ... 100
Gambar 4.9 Halaman Detil Perbaikan Produk ... 100
Gambar 4.10 Halaman Detil Perbaikan Produk ... 101
Gambar 4.11 Halaman Perkembangan Produk ... 102
Gambar 4.12 Halaman Detil Perkembangan Produk ... 102
Gambar 4.13 Halaman Penggantian Level Produk ... 103
ix
Gambar 4.16 Halaman Detil Penyelesaian Komplain ... 105
Gambar 4.17 Hasil Coba Uji Login Berhasil ... 108
Gambar 4.18 Hasil Uji Coba Login Gagal ... 108
Gambar 4.19 Hasil Uji Coba Memilih Jenis Produk Hardware ... 110
Gambar 4.20 Hasil Uji Coba Memilih Jenis Produk Software ... 110
Gambar 4.21 Hasil Uji Coba Data Pengajuan Tersimpan ... 111
Gambar 4.22 Hasil Uji Coba Notifikasi Kepala Bagian ... 111
Gambar 4.23 Hasil Uji Coba Menu Delegasi Komplain ... 113
Gambar 4.24 Hasil Uji Coba ProsesLihat Detil ... 113
Gambar 4.25 Hasil Uji Coba Data Pendelegasian Disimpan ... 114
Gambar 4.26 Hasil Uji Coba Notifikasi Tim ... 114
Gambar 4.27 Hasil Uji Coba Menu Perbaikan Komplain ... 116
Gambar 4.28 Hasil Uji Coba Proses Lihat Detil ... 116
Gambar 4.29 Hasil Uji Coba Data Perbaikan Disimpan ... 117
Gambar 4.30 Hasil Uji Coba Menu Penggantian Hardware ... 119
Gambar 4.31 Hasil Uji Coba Menu Penggantian Software ... 119
Gambar 4.32 Hasil Uji Coba Memilih Hardware Lama ... 119
Gambar 4.33 Hasil Uji Coba Data Penggantian Hardware Disimpan ... 119
Gambar 4.34 Hasil Uji Coba Data Penggantian Software Disimpan ... 120
Gambar 4.35 Hasil Uji Coba Menu Detil Jenis Komponen ... 121
Gambar 4.36 Hasil Uji Coba Menu Detil Jenis Form ... 121
Gambar 4.37 Hasil Uji Coba Memilih Komponen Lama ... 122
x
Gambar 4.40 Hasil Uji Coba Data Form Disimpan ... 122
Gambar 4.41 Hasil Uji Coba Menu Perkembangan Komplain ... 122
Gambar 4.42 Hasil Uji Coba Proses Lihat Detil Perkembangan ... 124
Gambar 4.43 Hasil Uji Coba Data Perkembangan Disimpan ... 124
Gambar 4.44 Hasil Uji Coba Menu Penyelesaian Komplain... 124
Gambar 4.45 Hasil Uji Coba ProsesLihat Detil ... 126
xi
Lampiran 1. BPMN Penanganan Komplain Perangkat Lunak Saat Ini ... 143
Lampiran 2. BPMN Penanganan Komplain Perangkat Keras Saat Ini ... 144
Lampiran 3. BPMN Aplikasi Penanganan Komplain Perangkat Lunak ... 145
Lampiran 4. BPMN Aplikasi Penanganan Komplain Perangkat Keras ... 146
Lampiran 5. Angket Uji Coba Pengguna Unit Eksternal ... 147
Lampiran 6. Angket Uji Coba Pengguna Kepala Bagian ... 150
Lampiran 7. Angket Uji Coba Pengguna Tim ... 152
Lampiran 8. Angket Uji Coba Pengguna Manajer ... 158
Lampiran 9. Angket Uji Coba Pengguna Ahli Sistem ... 159
Lampiran 10. Hasil Perbandingan Lama Pencarian Data Komplain ... 160
Lampiran 11. Kesesuaian Alur Sistem dengan Prosedur ... 161
Lampiran 12. Formulir Perbaikan ... 162
Lampiran 13. Laporan Hardware Per-Bulan ... 163
BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
PT Petrokimia Gresik merupakan produsen pupuk terlengkap di
Indonesia yang memproduksi berbagai macam pupuk, seperti: Urea, ZA,
SP-36, ZK, NPK Phonska, NPK Kebomas, dan pupuk Organik Petroganik. PT
Petrokimia Gresik juga memproduksi produk non pupuk, antara lain: Asam Sulfat,
Asam Fosfat, Amoniak, Dry Ice, Aluminum Fluoride, Cement Retarder, dll.
Keberadaan PT Petrokimia Gresik adalah untuk mendukung program Pemerintah
dalam rangka meningkatkan produksi pertanian dan ketahanan pangan Nasional.
Salah satu penunjang utama dari bisnis PT Petrokimia Gresik yaitu Departemen
Teknologi Informasi (TI). Pada departemen TI menyediakan serta mengelola
produk yang dibutuhkan dalam menjalankan kegiatan bisnis PT Petrokimia
Gresik. Produk tersebut meliputi komputer, printer, scanner, aplikasi desktop,
aplikasi website, dan lain-lain. Produk-produk tersebut tidak sedikit juga sering
mengalami kerusakan dan perlu dilakukan perbaikan hingga penggantian, oleh
karena itu Departemen TI berperan aktif dalam perbaikan dan penggantian produk
TI.
Departemen TI berperan aktif dalam mendukung jalannya kegiatan bisnis
PT Petrokimia Gresik seperti pembuatan website pemasaran produk, website
pengadaan barang/jasa, website penerimaan karyawan baru, penyediaan perangkat
keras TI, pengelolaan jaringan serta masih banyak aplikasi desktop yang dipakai
bagian yaitu Bagian Pengembangan Aplikasi dan Bagian Teknik dan Operasional.
Untuk pembagian tugas kerja, Bagian Pengembangan Aplikasi bertugas dalam
pembuatan dan penanganan komplain dari aplikasi desktop dan web, sedangkan
Bagian Teknik dan Operasional bertugas dalam pengelolaan dan penanganan
komplain dari perangkat keras dan jaringan komputer.
Dalam mengurus segala produk TI, Departemen TI sering mendapat
komplaininternal yaitu kerusakan produkseperti printer rusak, komputer tiba-tiba
mati, keyboard rusak, koneksi internet terputus, salah memasukkan data pada
aplikasi serta masih banyak kerusakan produk lain yang harus segera diperbaiki
untuk kelancaran bisnis. Pada kondisi saat ini, untuk mengajukan komplain
terdapat tiga cara. Pertama yaitu unit eksternal dapat mengubungi dengan telepon,
mengirim surat elektronik, dan mengirim Short Message Service (SMS) kepada
karyawan Departemen TI. Kedua, unit eksternal bisa datang langsung ke
Departemen TI untuk mengajukan komplain kepada karyawan. Ketiga, unit
eksternal dapat mengirim memo kepada Manajer Departemen TI. Untuk alur
penanganan komplain pada kondisi saat ini, dapat dilihat pada gambar di
Lampiran 1 dan 2.
Pada kondisi saat ini, proses yang terjadi dalam penanganan komplain
tidak dapat terdokumentasi dengan baik dikarenakan masih belum ada
standardisasi dokumen komplain sehingga dalam pencarian data komplain
membutuhkan waktu untuk mendapatkan data komplain. Selain itu penggunaan
kertas yang sudah ada dapat mempengaruhi biaya dari pengeluaran perusahaan.
penanganan komplain yang diajukan oleh unit eksternal karena karyawan tidak
pernah melakukan pencatatan perkembangan penanganan komplain.
Dari proses penanganan komplain pada Departemen TI yang terbilang
tidak efektif dan efisien, maka diperlukan manajemen komplain agar komplain
yang terjadi pada Departemen TI dapat ditangani dengan baik. Menurut Tjiptono
(2005) Manajemen komplain adalah bentuk penanganan atau penataan,
pengaturan yang dilakukan oleh suatu perusahaan dalam menyelesaikan atau
mengatasi sanggahan atau reaksi ketidakpuasan konsumen terhadap proses
penggunaan sumber daya organisasi, pengkoordinasian kegiatan organisasi, dan
kegiatan-kegiatan fungsi manajemen yang dilakukan tidak efektif dan efisien oleh
perusahaan tersebut. Suatu sistem penanganan komplain adalah cara yang
terorganisasi untuk menanggapi, mencatat laporan, dan menggunakan pengaduan
untuk meningkatkan layanan kepada pelanggan (Ombudsman, 2010). Dari kedua
teori yang dijelaskan, maka didapatkan risiko-risiko yang muncul dari penanganan
komplain saat ini antara lain:
a. Dokumen komplain yang belum di standardisasi.
b. Lamanya waktu dalam pencarian data komplain.
c. Tidak dapat memantau proses perkembangan penanganan komplain.
Berdasarkan proses penanganan komplain pada kondisi saat ini, maka
ditemukan permasalahan baru yaitu bagaimana memastikan alur proses
penanganan komplain dapat berjalan sesuai dengan prosedur yang ada. Agar alur
penanganan komplain dapat berjalan sesuai dengan prosedur yang ada, maka
diperlukan Administrative Workflow System. Administrative Workflow System
penggunaan form elektronik yang terhubung dengan surat elektronik. Sistem ini
biasa diaplikasikan ke dalam tugas-tugas administrasi rutin seperti persetujuan
pengajuan liburan, pemrosesan pemesanan pembelian, dll. (Chaffey, 1998)
Berdasarkan permasalahan di atas dan penjelasan teori yang ada, maka
diusulkan solusi untuk proses penanganan komplain yaitu dengan membuat
Aplikasi Penanganan Komplain menggunakan Administrative Workflow System.
Aplikasi tersebut dapat menangani proses penanganan komplain berjalan sesuai
prosedur yang ada. Selain itu, aplikasi juga dapat menginformasikan kepada
Manajer, Kepala Bagian dan unit eksternal dalam hal pemantauan perkembangan
penanganan komplain yang sedang dikerjakan oleh tim perbaikan produk. Dalam
alur proses penanganan komplain, aplikasi menerapkan Administrative Workflow
System untuk memastikan alur proses dapat berjalan dengan baik. Dengan
menggunakan Administrative Workflow System, aplikasi otomatis mengarahkan
komplain kepada orang yang berwenang dalam penanganan komplain melalui
push message. Selain itu, proses penanganan komplain lebih efekfif dan efisien.
Untuk usulan alur penanganan komplain, dapat dilihat pada gambar di Lampiran 3
dan 4.
1.2 Perumusan Masalah
Berdasarkan latar belakang penelitian yang sudah dijelaskan, maka dapat
ditarik beberapa rumusan permasalahan, yaitu:
1. Bagaimana menstandarkan dokumen komplain.
2. Bagaimana mempercepat dalam pencarian data komplain.
3. Bagaimana memudahkan Manajer dan Kepala Bagian dalam memantau data
4. Bagaimana memudahkan unit eksternal dapat mengetahui perkembangan
penanganan komplain yang telah diajukan.
5. Bagaimana memastikan alur proses penanganan komplain dapat berjalan sesuai
dengan prosedur yang ada.
1.3 Pembatasan Masalah
Berdasarkan rumusan masalah di atas, maka batasan masalah yang
digunakan dalam penelitian ini adalah sebagai berikut:
1. Penelitian hanya membahas penanganan komplain perangkat keras dan
perangkat lunak TI.
2. Tidak membahas pengadaan perangkat keras maupun perangkat lunak TI.
3. Push message melalui surat elektronik dan pemberitahuan pada aplikasi.
4. Penanganan prioritas komplain dilakukan oleh Kepala Bagian.
5. Waktu penyelesaian produk disesuaikan dengan Service Level Agreemenent
(SLA) masing-masing produk.
1.4 Tujuan Penelitian
Berdasarkan rumusan masalah dan batasan masalah di atas, maka tujuan
penelitian ini yaitu merancang dan membangun aplikasi penanganan komplain
menggunakan Administrative Workflow System yang mampu memastikan alur
proses penanganan komplain yang dimulai dari unit eksternal mengajukan
komplain hingga komplain dapat diselesaikan dengan baik.
1.5 Manfaat Penelitian
Manfaat dari rancang bangun aplikasi penanganan komplain untuk
1. Dengan Administrative Workflow System, alur penanganan komplain semakin
jelas dalam pendelegasian pihak-pihak yang berwenang.
2. Manajer, Kepala Bagian dan unit eksternal dapat melihat perkembangan
penanganan komplain yang sedang dikerjakan oleh karyawan.
3. Manajer dan Kepala Bagian dapat mengetahui hasil kerja masing-masing
karyawan.
4. Data komplain dapat dianalisis sebagai bahan evaluasi Manajer Departemen
TI.
5. Dapat mencegah ketidakpuasan unit eksternal di masa mendatang.
1.6 Sistematika Penulisan
Sistematika penulisan disusun dengan tujuan agar segala aktifitas yang
dilakukan dalam penelitian ini dapat terekam dalam bentuk laporan secara jelas
dan sistematis. Penyajiannya dibagi berdasarkan beberapa bab.
Pada bab pertama menjelaskan latar belakang masalah yang mendasari
penulis dalam merancang dan membangun aplikasi penanganan komplain. Bab ini
juga mencakup perumusan masalah, pembatasan masalah, tujuan penelitian,
manfaat penelitian dan sistematika penulisan laporan penelitian.
Pada bab kedua menjelaskan mengenai teori-teori yang mendukung
dalam penyelesaian penelitian, yaitu: manajemen komplain, Workflow
Management Systems (WFMS), Administrative Workflow System (AWS),
perangkat lunak, perangkat keras, model waterfall dan black box testing.
Teori-teori ini yang digunakan oleh penulis dalam menyelesaikan laporan dan sistem
Pada bab ketiga berisi tentang penjelasan dari analisis sistem dan desain
sistem yang dilakukan oleh penulis. Pada bagian analisis sistem dijelaskan tentang
sistem yang ada sekarang, dilanjutkan dengan analisis dari permasalahan yang
ada. Setelah melakukan analisis, dilakukan desain sistem yang menjelaskan
bagaimana sistem ini dibuat. Desain sistem digambarkan menggunakan Business
Process Modelling Notation (BPMN), Data Flow Diagram, Entity Relationship
Diagram, dan desain interface.
Pada bab keempat menjelaskan mengenai hasil implementasi dari analisis
dan perancangan sistem yang telah dilakukan. Bab ini menunjukkan tampilan dari
aplikasi yang telah dibuat, serta analisis dari hasil uji coba aplikasi yang telah
dilakukan.
Pada bab kelima menjelaskan tentang kesimpulan dari hasil analisis dan
perancangan aplikasi penanganan komplain. Selain itu, pada bab ini berisi tentang
pembahasan permasalahan yang telah dilakukan dan saran bagi pengembangan
aplikasi penanganan komplain sehingga aplikasi dapat disesuaikan dengan seiring
1
BAB II
LANDASAN TEORI
Dalam merancang dan membangun aplikasi, sangatlah penting untuk
mengetahui terlebih dahulu dasar-dasar teori yang digunakan. Dasar-dasar teori
tersebut digunakan sebagai landasan berpikir dalam melakukan pembahasan lebih
lanjut sehingga terbentuk suatu aplikasi yang sesuai dengan tujuan awal.
1.1 Manajemen Komplain
Dalam menerima jasa atau pelayanan sebuah perusahaan jasa ada kalanya
mengalami ketidakpuasan atas layanan jasa tersebut. Ketidakpuasan tersebut dapat
dinyatakan dalam bentuk pernyataan yang disebut komplain. Komplain
merupakan sanggahan atau sikap menentang/menyanggah yang dinyatakan
sebagai reaksi atas ketidakpuasan terhadap suatu layanan jasa. Komplain
menandakan adanya perasaan kekesalan atau kekecewaan akan sesuatu yang
didapatkan. Hal ini mengidentifikasikan bahwa apa yang didapat tidak sesuai
dengan harapan (Kottler, 1997). Pelayanan yang diberikan oleh penyelenggara
layanan, baik berupa barang atau jasa tidak semuanya mampu memberikan
kepuasan bagi pelanggan. Menurut Tjiptono (2005) Manajemen Komplain adalah
bentuk penanganan atau penataan, pengaturan yang dilakukan oleh suatu
perusahaan dalam menyelesaikan atau mengatasi sanggahan atau reaksi ketidak
2
pengoordinasian kegiatan organisasi, dan kegiatan-kegiatan fungsi manajemen
yang dilakukan tidak efektif dan efisien oleh perusahaan tersebut.
Mekanisme komplain sangat diperlukan dalam penyelenggaraan
pelayanan publik terutama bagi penyedia layanan untuk memperbaiki sistem
pelayanan. Perbaikan sistem ini dilakukan dengan memanfaatkan respon yang
diperoleh dan mengelolanya menjadi bahan pengambilan keputusan. Mekanisme
komplain adalah suatu bagian dari sistem pelayanan publik untuk memfasilitasi,
mengakomodasi, dan mengelola komplain konsumen atas pelayanan publik yang
diterimanya. Mekanisme tersebut meliputi prosedur pengajuan, perangkat
organisasi, mekanisme transparasi, media partisipasi konsumen dan perangkat
pemberdayaan masyarakat (Suprapto, 2006).
Menurut Ombudsman (2010) mengemukakan bahwa suatu sistem
penanganan komplain adalah cara yang terorganisasi untuk menanggapi, mencatat
laporan, dan menggunakan pengaduan untuk meningkatkan layanan kepada
pelanggan. Di dalamnya termasuk prosedur-prosedur bagi pelanggan untuk
membuat pengaduan dan pedoman bagi karyawan untuk menyelesaikan komplain,
serta menyediakan informasi kepada manajer dan staf yang dapat membantu
untuk mencegah ketidakpuasan pelanggan di masa mendatang. Sistem pengolahan
pengaduan yang efektif merupakan bagian penting dari sektor pelayanan publik
yang berkualitas. Kebijakan dan prosedur yang baik dalam penanganan komplain
mencakup informasi sebagai berikut:
a. Definisi Komplain
b. Siapa saja yang diperbolehkan mengeluh
3
d. Penjelasan tentang proses pengaduan
e. Peninjauan ulang (baik internal maupun eksternal)
f. Kebutuhan komunikasi termasuk waktu respon
g. Keadilan dan kesetaraan persyaratan
h. Privasi dan kesetaraan persyaratan
i. Bantuan yang tersedia untuk mengajukan komplain.
Menurut Ombudsman (2010) terdapat sebelas kebijakan dan prosedur
penanganan komplain efektif yang terdiri dari:
a. Commitment
b. Visibility and access
c. Responsiveness
d. Fairness
e. Resolutions
f. Service improvement
g. Data collection
h. Accountability
i. Review
j. Assistance
k. Charges
Sementara itu menurut Tjiptono (2008) terdapat empat aspek penting
dalam menangani komplain pelanggan, yaitu empati terhadap pelanggan,
kecepatan dalam penanganan komplain, kewajaran/keadilan dalam menyelesaikan
4
1.2 Workflow Management System
Menurut Chaffey (1998), Workflow Management System (WfMS)
sebagai tipe perangkat lunak khusus yang digunakan untuk membantu kerja
kolaboratif dengan komputer dan sering disebut sebagai otomatisasi Workflow,
karena WfMS bisa mengotomatisasi tugas atau aktifitas yang dilakukan manusia
atau komputer dari sebuah organisasi.
Workflow Management Coalition (WfMC) menggambarkan workflow
sebagai fasilitas komputerisasi atau otomatisasi proses bisnis secara keseluruhan
atau sebagian, sedangkan WfMS digambarkan sebagai sebuah sistem yang
mendefinisikan, menciptakan, dan mengelola pelaksanaan workflow melalui
penggunaan perangkat lunak, yang berjalan pada satu atau lebih workflow engine,
yang mampu menafsirkan definisi proses, berinteraksi dengan peserta alur kerja
dan, jika diperlukan, meminta penggunaan alat dan aplikasi TI.
Workflow dapat memberikan perbedaan yang besar pada efisiensi
operasional dari proses yang ada pada sebuah bisnis. Workflow dapat membantu
manajer dalam mengoordinasikan tugas-tugas yang dilakukan oleh staf dan
memberikan informasi kepada staf untuk membantu manajer melakukan
tugas-tugasnya. Keuntungan bisnis utama dari penerapan sebuah sistem workflow adalah
waktu penyelesaian dan biaya dari proses bisnis yang ada sekarang dapat
dikurangi (Chaffey, 1998).
2.2.1 Elemen Kerja Kunci dalam Workflow System
Sebuah workflow dapat digambarkan sebagai suatu hal yang terdiri atas
serangkaian kegiatan, yang bersama-sama, membentuk sebuah proses bisnis. Pada
5
workitem individu yang harus diselesaikan. Setiap workitem disini dilakukan oleh
sebuah resource, baik perangkat lunak, perangkat keras, atau seorang personil
yang memiliki tanggung jawab untuk melakukannya. Work item yang akan
diselesaikan ditunjukkan pada sebuah workflow queue, yang adalah sebuah daftar
kerja dari semua tugas yang akan diselesaikan oleh seorang individu atau sebuah
tim.
Gambar 2.1 kerja kunci dalam WorkflowSystem (Chaffey, 1998)
1. Process Elements (Work Activities and Tasks)
Aktifitas kerja atau tugas adalah unit kerja individu yang membentuk
workflow. Aktifitas-aktifitas ini biasanya bisa diuraikan menjadi sub tugas yang
membentuk sebuah hirarki tugas. Pada saat sebuah aktifitas kerja diselesaikan,
perubahan status sebuah obyek akan terjadi dan perlu dicatat oleh sistem.
2. Resources and Their Roles
Resources adalah sumber daya manusia atau komputer yang melakukan
aktifitas kerja yang membangun proses bisnis. User atau computer resource,
yang dikenal sebagai workflow participant diberikan satu atau beberapa peran
yang akan menentukan apakah mereka dapat melakukan tugas tertentu.
Business Process
Activity (or Tasks)
Business Rule (or Process Definition)
Work Item Resource
(Computer or Human) Workflow Queue
Broken Down Into
Define Sequance
Broken Down Into
6
Penggunaan peran daripada individu lebih penting karena akan memudahkan
untuk memindahkan tanggung jawab seseorang ke orang lain dengan peran
yang sama. Pada situasi tertentu, adalah penting untuk menentukan bahwa
sebuah tugas ditingkatkan pada sebuah peran yang berbeda.
3. Dependencies and Business Rules
Dependencies (dependensi) menjelaskan bagaimana aktifitas yang berbeda
berhubungan satu sama lain. Dependensi didefinisikan oleh business rules yang
membangun workflow. Urutan dari aktifitas dapat diatur berdasarkan
pre-condition atau post-condition yang harus dipenuhi sebelum mulai atau
selesainya sebuah aktifitas.
4. Workflow Queue
Sistem workflow biasanya menerapkan sebuah antrian workflow yang
digunakan untuk menugaskan sebuah tugas ke individu. Sebuah urutan
workflow akan menampung sebuah daftar tugas atau aktifitas yang harus
dikerjakan dalam sebuah urutan prioritas.
5. Case Management
Penggunaan dari sebuah case atau tiruan dari folder adalah sebuah hal yang
umum pada sistem workflow. Sebuah case akan terdiri atas sebuah instance
tunggal dari subyek dan obyek yang utama dari workflow, yaitu customer.
Setiap case dapat digambarkan sebagai sebuah berkas dari sebuah lemari arsip
yang menyimpan semua informasi yang berhubungan dengan customer.
6. Messaging
Pesan tambahan dapat dikirim antara teman sekerja ketika terjadi kejadian yang
7
menggunakan standard company mail system, atau sistem workflow akan
mengijinkan sebuah notifikasi untuk dikeluarkan atau dapat mengijinkan
perubahan jalur sebuah tugas atau pencabutan sebuah tugas.
2.2.2 Administrative Workflow System
Administrative Workflow System adalah sebuah sistem workflow umum
digunakan, yang memanfaatkan penggunaan form elektronik yang terhubung
dengan surat elektronik. Sistem ini biasa diaplikasikan ke dalam tugas-tugas
administrasi rutin seperti persetujuan pengajuan liburan, pemrosesan pemesanan
pembelian, dll. The Gartner Group memperkirakan bahwa 83% dari semua
dokumen bisnis di US adalah dokumen formulir dengan biaya pembelian tahunan
sebesar 6-8 milyar USD dan biaya pemroresan mencapai 360 milyar USD.
Formulir-formulir kertas ini menjadi target dari 1995 Paper Reduction Act.
(Chaffey, 1998)
Manfaat yang besar dapat terjadi melalui mengotomatisasikan proses
berbasis formulir. proses dapat berbalik lebih cepat menggunakan formulir
elektronik dan mengurangi biaya melalui pengurangan biaya pembelian formulir
dan waktu siklus yang lebih pendek. salah satu penghematan biaya terbesar adalah
dalam koordinasi pengolahan formulir yang sekarang ditangani oleh logika bisnis
yang dibangun ke dalam aplikasi. (Chaffey, 1998)
1.3 Perangkat Lunak (Software)
Perangkat lunak (software) adalah (1) perintah (program komputer) yang
bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan. (2)
8
proporsional. (3) dokumen yang menggambarkan operasi dan kegunaan program
(Pressman, 2012a). Perangkat lunak tidak hanya program komputer saja, tetapi
juga semua dokumentasi terkait dan data konfigurasi yang diperlukan untuk
membuat program tersebut beroperasi dengan benar (Sommerville, 2001).
Menurut Pressman (2012a), perangkat lunak lebih merupakan elemen
logika dan bukan merupakan elemen sistem fisik. Dengan demikian, perangkat
lunak memiliki ciri yang berbeda dari perangkat keras:
1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang
klasik.
2. Perangkat lunak tidak pernah usang.
3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat
dirakit dari komponen yang sudah ada.
Terdapat 2 tipe dari produk perangkat lunak menururt Sommerville
(2001), yaitu:
1. Generic Software
Perangkat lunak generik adalah perangkat lunak mandiri (stand-alone) yang
diproduksi oleh sebuah perusahaan pengembangan perangkat lunak dan dijual
di pasaran secara bebas.
2. Custom Software
Custom software (atau yang dipesan terlebih dahulu) adalah perangkat lunak
yang dipesan oleh seorang pembeli tertentu. Perangkat lunak ini dikembangkan
9
1.4 Perangkat Keras (Hardware)
Perangkat keras komputer adalah alat pengolah data yang bekerja secara
elektronis dan otomatis. Perangkat keras komputer dapat bekerja apabila ada
unsur manusia yang mengerti tentang alat itu dan dapat bekerja menggunakan alat
itu. Komputer merupakan sistem karena merupakan sekumpulan objek yang
berhubungan dan bekerjasama untuk menghasilkan sesuatu yang diinginkan.
(Suyanto, 2005)
Dalam buku Pengantar Teknologi untuk Bisnis, Suyanto (2005)
mengelompokkan sistem perangkat keras komputer menjadi empat unsur utama
dan satu unsur tambahan yaitu Unit Masukan, Central Processing Unit (CPU),
Storage Memory, Unit Keluaran, dan unsur tambahan Communication Link.
Macam-macam perangkat keras komputer yaitu:
1. Unit Masukan: Mouse, Joystick, Trackball, Trackpad, Trackpoint,
Touchscreen, LightPen, DigitizingTablet, UnitRemoteControl.
2. Alat Masukan Otomatisasi Data: Optical Mark Reader (OMR), Optical
Character Reader (OCR), Handheld Scanner, Flatbed Scanner, Path-through
Scanner, FilmScanner, Digital Camera, Camcorder, Snappy.
3. Unit Keluaran: Monitor, Printer, Plotter, Microform, Microfilm, Microfich,
Projector, Speaker.
4. Alat Masukan Keluaran: Poin of Sale (POS), Soundcard, MIDI Sport, Digital
Versaitle Disc (DVD) dan Compact Disc (CD).
2.5 Web
Menurut Shelly dan Vermalat (2010), web adalah koleksi dokumen
10
menggunakan web browser. Menurut Simamarta (2010), aplikasi web adalah
sebuah sistem informasi yang mendukung interaksi pengguna melalui antarmuka
berbasis web. Fitur-fitur aplikasi web biasanya berupa data persistence, mendukng
transaksi dan komposisi halaman web dinamis yang dapat dipertimbangkan
sebagai hibridasi, antara hypermedia dan sistem informasi. Aplikasi web adalah
bagian dari client-side yang dapat dijalankan oleh browser web. Client-side
mempunyai tanggung jawab untuk pengeksekusian proses bisnis.
Interaksi web menurut simamarta (2010), dibagi dalam tiga langkah
utama, yaitu:
1. Permintaan
Pengguna mengirimkan permintaan ke server web, biasanya via halaman web
yang ditampilkan pada browser web.
2. Pemrosesan
Server web menerima permintaan yang dikirimkan oleh pengguna, kemudian
memproses permintaan tersebut.
3. Jawaban
Browser menampilkan hasil dari permintaan pada jendela browser.
2.6 Siklus Hidup Pengembangan Sistem
Menurut Kendall dan Kendall (2008), Siklus Hidup Pengembangan
Sistem, nama lain dari System Development Life Cycle (SDLC) ini merupakan
suatu proses pengembangan atau perubahan suatu sistem perangkat lunak.
Pengembangan atau perubahan tersebut dilakukan dengan menggunakan
model-model dan metodologi yang digunakan oleh banyak orang, yang telah
11
berdasarkan best practice atau cara-cara yang telah teruji dengan baik oleh banyak
orang yang menggunakannya. SDLC memiliki beberapa model dalam penerapan
tahapan prosesnya. Beberapa model SDLC tersebut antara lain yaitu Model
Waterfall, Spiral, Rapid Application Development, Agile dan Prototype.
Masing-masing model memiliki kelemahan dan kelebihan, sehingga hal yang terpenting
adalah mengenali tipe pelanggan dan memilih menggunakan model SDLC yang
sesuai dengan karakter pelanggan dan sesuai dengan karakter pengembang
perangkat lunak.
Menurut Pressman (2012b), System Develoment Life Cycle (SDLC) ini
biasanya disebut juga dengan model waterfall. Menurut Pressman (2012b), nama
lain dari Model Waterfall adalah Model Air Terjun, kadang dinamakan siklus
hidup klasik (classic life cyle), dimana hal ini menyiratkan pendekatan yang
sistematis dan berurutan (sekuensial) pada pengembangan perangkat lunak.
Pengembangan perangkat lunak dimulai dari spesifikasi kebutuhan pengguna dan
berlanjut melalui tahapan-tahapan perencanaan (planning), pemodelan
(modeling), konstruksi (construction), serta penyerahan sistem perangkat lunak ke
para pelanggan/pengguna (deployment), yang diakhiri dengan dukungan
berkelanjutan pada perangkat lunak yang dihasilkan.
Communication
12
Gambar 2.2 menunjukkan tahapan umum dari model proses waterfall.
Model ini disebut dengan waterfall karena tahap demi tahap yang dilalui harus
menunggu selesainya tahap sebelumnya dan berjalan berurutan. Akan tetapi,
Pressman (2012b) memecah model ini meskipun secara garis besar sama dengan
tahapan-tahapan model waterfall pada umumnya.
Model ini merupakan model yang paling banyak dipakai dalam Software
Engineering. Model ini melakukan pendekatan secara sistematis dan urut mulai
dari level kebutuhan sistem lalu menuju ketahap Communication, Planning,
Modeling, Construction, dan Deployment.
Berikut ini adalah penjelasan dari tahap-tahap yang dilakukan di dalam
Model Waterfall menurut Pressman (2012b):
a. Communication
Langkah pertama diawali dengan komunikasi kepada konsumen/pengguna.
Langkah awal ini merupakan langkah penting karena menyangkut
pengumpulan informasi tentang kebutuhan konsumen/pengguna.
b. Planning
Setelah proses communication ini, kemudian menetapkan rencana untuk
pengerjaan software yang meliputi tugas-tugas teknis yang akan dilakukan,
risiko yang mungkin terjadi, sumber yang dibutuhkan, hasil yang akan dibuat,
dan jadwal pengerjaan.
c. Modeling
Pada proses modeling ini menerjemahkan syarat kebutuhan sebuah
13
Proses ini berfokus pada rancangan struktur data, arsitektur software,
representasi interface, dan detail (algoritma) prosedural.
d. Construction
Construction merupakan proses membuat kode (code generation). Coding atau
pengkodean merupakan penerjemahan desain dalam bahasa yang bisa dikenali
oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh
user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan
suatu software, artinya penggunaan komputer akan dimaksimalkan dalam
tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap
sistem yang telah dibuat. Tujuan testing adalah menemukan
kesalahan-kesalahan terhadap sistem tersebut untuk kemudian bisa diperbaiki.
e. Deployment
Tahapan ini bisa dikatakan final dalam pembuatan sebuah software atau sistem.
Setelah melakukan analisis, desain dan pengkodean maka sistem yang sudah
jadi akan digunakan user. Kemudian software yang telah dibuat harus
dilakukan pemeliharaan secara berkala.
2.7 Testing
Menurut Romeo (2003), testing adalah proses pemantapan kepercayaan
akan kinerja program atau sistem sebagaimana yang diharapkan. Testing software
adalah proses mengoperasikan software dalam suatu kondisi yang dikendalikan
untuk verifikasi, mendeteksi error dan validasi. Verifikasi adalah pengecekan atau
pengetesan entitas-entitas, termasuk software, untuk pemenuhan dan konsistensi
dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan.
14
sudah sesuai dengan apa yang dibutuhkan oleh pengguna. Deteksi error adalah
testing yang berorientasi untuk membuat kesalahan secara intensif, untuk
menentukan apakah suatu hal tersebut terjadi bilamana tidak seharusnya terjadi
atau suatu hal tersebut tidak terjadi. Test case merupakan suatu tes yang dilakukan
berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah
ditentukan sebelumnya. Adapun kegunaan dari test case ini, adalah sebagai
berikut:
1. Untuk melakukan testing kesesuaian suatu komponen terhadap desain White
Box Testing.
2. Untuk melakukan testing kesesuaian suatu komponen terhadap spesifikasi
Black Box Testing.
2.7.1 White Box Testing
Menurut Romeo (2003), white box testing adalah suatu metode desain
test case yang menggunakan struktur kendali dari desain prosedural. Seringkali
white box testing diasosiasikan dengan pengukuran cakupan tes, yang mengukur
persentase jalur-jalir dari tipe yang dipilih untuk dieksekusi oleh test cases. White
box testing dapat menjamin semua struktur internal data dapat dites untuk
memastikan validitasnya.
Cakupan pernyataan, cabang dan jalur adalah suatu teknik white box
testing yang menggunakan alur logika dari program untuk membuat test cases
alur logika adalah cara dimana suatu bagian dari program tertentu dieksekusi saat
menjalankan program. Alur logika suatu program dapat direpresentasikan dengan
15
2.7.2 Black Box Testing
Menurut Romeo (2003), black box testing dilakukan tanpa adanya suatu
pengetahuan tentang detail struktur internal dari sistem atau komponen yang dites,
juga disebut sebagai functional testing. Black box testing berfokus pada kebutuhan
fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software.
Dengan adanya black box testing, perekayasa software dapat
menggunakan kebutuhan fungsional pada suatu program. Black box testing
dilakukan untuk melakukan pengecekan apakah sebuah software telah bebas dari
error dan fungsi-fungsi yang diperlukan telah berjalan sesuai dengan yang
diharapkan.
2.8 Skala Likert
Angket atau kuisioner adalah daftar pertanyaan yang diberikan kepada
orang lain yang bersedia memberikan respon, sesuai dengan permintaan
pengguna. Tujuan dari menyebarkan angket adalah mencari informasi dari
responden tanpa khawatir bila responden memberikan jawaban yang tidak sesuai
dengan kenyataan (Riduwan, 2005).
Menurut Husein (2003), skala likert berhubungan dengan pernyataan
seseorang terhadap sesuatu. Skor pada skala likert berarah positif dan negatif.
Skala likert digunakan untuk mengukur sikap, pendapat, dan presepsi seseorang
atau kelompok tentang kejadian atau gejala sosial.
Perhitungan skor penilaian untuk setiap pertanyaan (QS) didapatkan dari
jumlah pengguna (PM) dikalikan dengan skala nilai (N). Jumlah skor tertinggi
(STtot) didapatkan dari skala tertinggi (NT) dikalikan jumlah pertanyaan (Qtot)
16
skor hasil pengumpulan data (JSA) dibagi jumlah skor tertinggi (STot) dikalikan
100%. Persamaan 2.1, 2.2, dan 2.3 adalah persamaan dengan menggunakan Skala
Likert.
QS(n) = PM x N (2.1)
STtot = NT x Qtot x Ptot (2.2)
Pre = JSA / STtot x 100% (2.3)
Keterangan:
QS(n) = Skor pertanyaan ke-n
PM = Jumlah pengguna yang menjawab
N = Skala nilai
STtot = Total skor tertinggi
NT = Skala nilai tertinggi
Qtot = Total pertanyaan
Ptot = Total pengguna
Pre = Persentase akhir (%)
JSA = Jumlah skor akhir
Analisis dilakukan dengan melihat persentase akhir dari proses
perhitungan skor. Nilai persentase kemudian dicocokkan dengan kriteria
interpretasi skor yang dapat dilihat pada Tabel 2.1.
Tabel 2.1 Keterangan Nilai Skala Likert (Husein, 2003)
Nilai Keterangan
0% – 20% Sangat Kurang
21% – 40% Kurang
41% – 60% Cukup
61% – 80% Baik
1
BAB III
ANALISIS DAN PERANCANGAN SISTEM
Pada bab ini dijelaskan mengenai analisis dari permasalahan yang
diambil pada Departemen Teknologi Informasi PT Petrokima Gresik. Selain itu,
bab ini juga merancangan desain sistem dari Rancang Bangun Aplikasi
Penanganan Komplain menggunakan Administrative Workflow System.
3.1 Analisis Sistem
Pada tahap analisis dilakukan beberapa proses yang berhubungan dengan
tahapan awal metode penelitian. Pada metode penelitian yang diambil
menggunakan model waterfall. Pada model waterfall terdapat beberapa tahapan
yang meliputi tahap komunikasi, tahap perencanaan, tahap pemodelan, tahap
konstruksi dan tahap penerapan aplikasi. Pada tahap analisis sistem membahas
tentang komunikasi dan perencanaan.
3.1.1 Komunikasi
Pada tahap komunikasi, dilakukan proses observasi dan wawancara.
Proses observasi dilakukan dengan cara mengamati secara langsung kebagian
komersial dan website perusahaan yang bertujuan untuk mengetahui informasi
tentang nama perusahaan, bidang usaha, gambaran umum perusahaan, visi dan
misi perusahaan. Sedangkan pada proses wawancara dilakukan dengan cara
melakukan proses tanya jawab kepada beberapa karyawan Departemen Teknologi
Informasi yang berfungsi untuk mencocokkan data dan informasi dari hasil
2
beberapa hal yang tidak didapat dari hasil observasi. Proses wawancara dilakukan
pada bagian pengembangan aplikasi oleh tiga karyawan kemudian bagian teknik
dan operasional dua karyawan dan satu kepala bagian pengembangan aplikasi.
Pada tahap komunikasi dilakukan proses analisis bisnis, analisis kebutuhan
pengguna, analisis kebutuhan data dan analisis kebutuhan fungsi.
A Analisis Bisnis
Pada proses analisis bisnis dituliskan hasil dari observasi dan wawancara
secara rinci tentang proses penanganan komplain yang terjadi pada saat ini. Pada
proses analisis bisnis dapat disusun empat identifikasi yaitu identifikasi masalah,
identifikasi pengguna, identifikasi data dan identifikasi fungsi.
1. Identifikasi masalah
Pada proses identifikasi masalah, dilakukan penggambaran proses bisnis yang
dihasilkan dari wawancara dan observasi. Peneliti menggambarkan proses
bisnis yang ada pada saat ini dengan menggunakan BPMN (Business Process
Model and Notation). Dari penggambaran proses bisnis yang ada, maka
ditemukan beberapa permasalahan. Permasalahan yang muncul yaitu mengenai
penanganan komplain. Dari proses penanganan komplain yang terjadi pada saat
ini, maka terdapat beberapa masalah yaitu:
a. Dokumen komplain yang belum di standardisasi
Pada dokumen komplain yang belum distandardisasi, peneliti memberikan
solusi untuk merancang beberapa dokumen yaitu dokumen pengajuan,
dokumen pendelegasian, dokumen pencatatan kerusakan, dokumen
3
b. Lamanya waktu dalam pencarian data komplain
Untuk menyelesaikan permasalahan dalam mempercepat pencarian data,
peneliti merancang aplikasi website. Aplikasi website dapat melakukan
pencarian data dengan cepat dari pada melakukan pencarian data manual.
c. Unit eksternal, kepala bagian dan tim perbaikan produk tidak dapat
mengetahui perkembangan penanganan komplain.
Untuk dapat mengetahui perkembangan komplain, maka peneliti membuat
aplikasi website yang nantinya tim perbaikan diwajibkan untuk melakukan
pencatatan perkembangan pada aplikasi website disetiap setelah
melakukan perbaikan komplain. Dengan pencatatan tersebut, maka unit
eksternal, kepala bagian dan tim perbaikan dapat mengetahui
perkembangan komplain.
d. Alur penanganan komplain yang rumit
Untuk menyelesaikan permasalahan alur penanganan komplain yang
rumit, maka peneliti menyusun BPMN kondisi saat ini yang terlampir pada
lampiran satu dan dua. Dari proses bisnis yang digambarkan pada BPMN,
kemudian peneliti merancang alur proses bisnis solusi dengan kesepakatan
bersama antara peneliti dengan pihak Departemen TI.
2. Identifikasi pengguna
Setelah ditemukan beberapa permasalahan yang muncul, maka dapat dilakukan
identifikasi pengguna. Pada proses penanganan komplain, pengguna yang ada
yaitu unik eksternal atau seluruh pegawai PT Petrokimia Gresik, tim perbaikan
produk, kepala bagian pengembangan aplikasi dan kepala bagian teknik dan
4
3. Identifikasi data
Pada tahap identifikasi data diperlukan beberapa data untuk merancang aplikasi
penanganan komplain. Data tersebut meliputi data pegawai, data bagian, data
departemen, data jabatan, data tim, data software, data form, data hardware,
data komponen dan data komplain.
4. Identifikasi fungsi
Setelah dilakukan proses identifikasi permasalahan, pengguna dan data, maka
dapat dilakukan proses identifikasi fungsi. Identifikasi fungsi menghasilkan
beberapa fungsi yaitu fungsi pengajuan, fungsi pendelegasian, fungsi
pencatatan kerusakan, fungsi penggantian, fungsi perkembangan serta fungsi
penyelesaian komplain.
Departemen satu dengan yang lain di PT Petrokimia Gresik lokasinya
berjauhan, sehingga untuk melakukan proses pengajuan maupun pemantauan
komplain membutuhkan waktu yang lama. Kemudian pada departemen TI sudah
tersedia jaringan yang dipakai untuk membantu kegiatan bisnis PT Petrokimia
Gresik. Jaringan tersebut juga sebagai media dalam penggunaan beberapa aplikasi
website yang menggunakan wifi dan kabel LAN. Oleh karena itu, peneliti
menetapkan bahwa aplikasi menggunakan arsitektur web. Dengan aplikasi web
maka unit eksternal dapat melakukan pengajuan komplain dengan cepat,
disamping itu kepala bagian dan tim perbaikan juga dapat mengetahui
perkembangan penanganan komplain.
B Analisis Kebutuhan Pengguna
Berdasarkan hasil wawancara dengan bagian Departemen Teknologi
5
bahwa sudah tersedia wifi dan LAN sebagai media penyalur data yang disebabkan
jarak antara departemen satu dengan lain saling berjauhan. Dari permasalahan
jarak yang berjauhan tersebut, maka aplikasi menggunakan arsitektur sistem web
based. Dengan arsitektur web based apa bila terjadi kerusakan pada aplikasi tidak
perlu melakukan replace aplikasi pada masing-masing komputer yang digunakan
oleh pengguna. Dengan demikian cara perbaikan hanya dengan memperbaiki
melalui server dari aplikasi maka aplikasi akan update secara otomatis pada
semua komputer pengguna. Kebutuhan pengguna berfungsi untuk mengetahui
kebutuhan dari masing-masing pengguna yang berhubungan langsung dengan
aplikasi sehingga aplikasi yang dibuat dapat sesuai dengan apa yang diminta oleh
pengguna dan sesuai dengan kebutuhan bisnis. Terdapat tiga pengguna yang
berhubungan dengan aplikasi yaitu pengguna unit eksternal, pengguna kepala
bagian dan pengguna tim perbaikan. Untuk lebih jelasnya dapat dilihat pada
tabel-tabel yang ada dibawah ini.
1. Pengguna Unit Eksternal
Tabel 3.1 Kebutuhan Pengguna Unit Eksternal
Fungsi Data Informasi
Pengajuan Komplain
1. Pegawai
2. Departemen
3. Bagian
4. Komplain
5. Hardware
6. Software
1. Pengajuan Komplain
2. Notifikasi Pengajuan Komplain
Penyelesaian komplain
1. Pegawai
2. Komplain
3. Tim
perbaikan
4. Hardware
5. software
6. komponen
7. form
1. Konfirmasi Kesesuaian Komplain
6
2. Pengguna Kepala Bagian
Tabel 3.2 Kebutuhan Pengguna Kepala Bagian
Fungsi Data Informasi
Pendelegasian
1. Pegawai
2. Departemen
3. Bagian
4. Jabatan
5. Komplain
6. Tim
perbaikan
7. Hardware
8. software
1. Pendelegasian komplain
2. Notifikasi pendelegasian komplain
3. Tim Perbaikan
Tabel 3.3 Kebutuhan Pengguna Tim Perbaikan
Fungsi Data Informasi
Pencatatan kerusakan
1. Pegawai
2. Komplain
3. Tim
perbaikan
4. Hardware
5. software
6. komponen
7. form
1. Hasil kerusakan produk
2. Perkembangan komplain
Penggantian Produk
1. Pegawai
2. Komplain
3. Tim
perbaikan
4. Hardware
5. software
6. komponen
7. form
1. Produk lama
2. Produk baru
3. Perkembangan Kompalin
4. Notifikasi Penyelesaian
Perkembangan komplain
1. Pegawai
2. Komplain
3. Tim
perbaikan
4. Hardware
5. software
6. komponen
7. form
1. Perkembangan Komplain
7
C Analisis Kebutuhan Data
Dari beberapa kebutuhan fungsi yang telah disusun sebelumnya, maka
dibutuhkan beberapa data untuk menunjung sistem yang akan dibuat. Terdapat 10
data yang diperlukan sistem, data tersebut meliputi:
1. Data Pegawai
Data pegawai telah disediakan oleh pihak perusahaan, dan peneliti diberi
akses untuk membaca data pegawai sebagai data tambahan untuk pembuatan
aplikasi penanganan komplain. Data pegawai yang diperlukan meliputi NIK,
nama pegawai, email pegawai serta password pegawai untuk dapat login ke
aplikasi.
2. Data Bagian
Data bagian telah disediakan oleh pihak perusahaan, dan peneliti diberi akses
untuk membaca data bagian sebagai data tambahan untuk pembuatan aplikasi
penanganan komplain. Data bagian yang diperlukan meliputi Kode bagian
dan nama bagian.
3. Data Departemen
Data departemen telah disediakan oleh pihak perusahaan, dan peneliti diberi
akses untuk membaca data departemen sebagai data tambahan untuk
pembuatan aplikasi penanganan komplain. Data departemen yang diperlukan
meliputi Kode departemen dan nama departemen.
4. Data Jabatan
Data jabatan telah disediakan oleh pihak perusahaan, dan peneliti diberi akses
8
penanganan komplain. Data jabatan yang diperlukan meliputi Kode jabatan
dan nama jabatan.
5. Data Tim
Data tim berfungsi sebagai pembuat dan pemelihara software maupun
hardware yang terdiri dari beberapa anggota atau karyawan TI. Data tim yang
diperlukan meliputi kode tim, nama tim, periode tim serta status tim. Data tim
masih belum ada pada perusahaan, oleh karena itu peneliti membuat data tim
dari awal.
6. Data Software
Data software berfungsi sebagai penampung nama-nama software yang sudah
ter-install pada seluruh departemen PT Petrokimia Gresik. Data software
yang dibutuhkan meliputi kode software, nama software, versi software,
keterangan software dan status software.Data software masih belum ada pada
perusahaan, oleh karena itu peneliti membuat data software dari awal.
7. Data Form
Data form berfungsi sebagai penampung nama-nama form yang terdapat pada
software. Data form yang dibutuhkan meliputi kode form, nama form dan
status form. Data form masih belum ada pada perusahaan, oleh karena itu
peneliti membuat data form dari awal.
8. Data Hardware
Data hardware berfungsi sebagai penampung nama-nama hardware yang
sudah ada pada seluruh departemen PT Petrokimia Gresik. Data hardware
9
hardware. Data hardware masih belum ada pada perusahaan, oleh karena itu
peneliti membuat data hardware dari awal.
9. Data Komponen
Data komponen berfungsi sebagai penampung nama-nama komponen yang
terdapat pada hardware. Data komponen yang dibutuhkan meliputi kode
komponen, nama komponen dan status komponen. Data komponen masih
belum ada pada perusahaan, oleh karena itu peneliti membuat data komponen
dari awal.
10. Data Komplain
Data komplain berfungsi sebagai transactional dari proses pengajuan
komplain. Data komplain yang dibutuhkan meliputi kode komplain, tanggl
masuk, prioritas, diskripsi komplain, status notifikasi serta diskripsi
kesesuaian. Data komplain masih belum ada pada perusahaan, oleh karena itu
peneliti membuat data komplain dari awal.
D Analisis Kebutuhan Fungsi
Berdasarkan User Requirementyang sudah dibuat sebelumnya, maka
dapat dirancang kebutuhan fungsi dari aplikasi. Pada tahap kebutuhan fungsi
digunakan untuk mengimplementasikan seluruh fungsi yang didapatkan dari hasil
analisis kebutuhan pengguna. Fungsi- fungsi tersebut dapat dibagi menjadi 8
fungsi yang meliputi sebagai berikut:
1. Fungsi Pengajuan Komplain
Tabel 3.4 Fungsi Pengajuan Komplain
10
Diskripsi Fungsi ini digunakan oleh unit eksternal untuk mengajukan komplain
dengan memasukkan data komplain
Pemicu Kondisi hardware atau software
Awal Otentikasi (Unit Eksternal)
Alur Normal Aksi Stakeholder Respon Sistem
Aktor memilih tipe produk komplain Sistem menampilkan nama produk (hardware/software) yang diambil dari table
hardware dan software Aktor mengisi diskripsi komplain Sistem menampung
diskripsi komplain Aktor menekan tombol save 1. Sistem mencetak auto
increment komplain 2. Sistem menyimpan data
komplain kedalam database sekaligus membuat status
komplain menjadi Baru 3. Sistem mengirim
notifikasi komplain kepada kepala bagian 4. Sistem mengosongkan
semua isian dalam form komplain
Akhir Data komplain tersimpandan terkirim berupa notifikasi
Non Fungsional
Pengajuan komplainhanya hanya boleh dilakukan oleh karyawan PT Petrokimia Gresik
2. Fungsi Pendelegasian Komplain
Tabel 3.5 Fungsi Pendelegasian Komplain
Aktor Kepala Bagian
Diskripsi Fungsi ini digunakan oleh Kepala Bagian Pengembangan Aplikasi
dan Kepala Bagian Teknik & Operasional untuk membagi dan mendelegasikan komplain yang diajukan oleh unit eksternal kepada Tim Perbaikan sesuai dengan jobdesc yang telah ditentukan sebelumnya
Pemicu Fungsi pengajuan komplain
Awal Otentikasi (Kepala Bagian Pengembangan Aplikasi dan Kepala
Bagian Teknik&Operasional), Notifikasi
Alur Normal Aksi Stakeholder Respon Sistem
Aktor meng-klik menu pendelegasian komplain
11
software masuk ke kepala bagian Bang Apli
sekaligus memfilter komplain yang berstatus baru.
Aktor memilih salah satu id komplain untuk dilakukan pendelegasian
1. Sistem menampilkan detil data komplain yang belum dilakukan pendelegasian dan status komplain baru 2. Sistem menampilkan Id
TIM berdasarkan software atau hardware yang dikomplain, dengan TIM yang menangani produk tersebut.
Aktor menentukan prioritas komplain (Tinggi / Sedang)
Sistem menampung data prioritas
Aktor menekan tombol save 1. Sistem menyimpan data pendelegasian sekaligus merubah status
komplain menjadi Delegasi
2. Sistem mengirimkan notifikasi kepada Tim Perbaikan yang telah dipilih oleh kepala bagian
3. Sistem menampilkan data komplain dari unit eksternal berdasarkan komplain yang belum dilakukan
pendelegasian
Akhir Data pendelegasian komplain tersimpan dan terkirim berupa
notifikasi
Non Fungsional 1. Pendelegasian hanya boleh dilakukan oleh kepala bagian.
2. Ada 1 orang yang ditunjuk sebagai pengganti pendelegasian kepala bagian apabila kepala bagian mendapat tugas dinas
3. Fungsi Pencatatan Kerusakan Produk
Tabel 3.6 Tabel Fungsi Pencatatan Kerusakan
Aktor Tim Perbaikan
Diskripsi Fungsi ini digunakan oleh tim perbaikan untuk melakukan
12
Pemicu Fungsi Pendelegasian
Awal Otentikasi (Tim Perbaikan), Notifikasi
Alur Normal Aksi Stakeholder Respon Sistem
Aktor memilih data komplain 1.Sistem menampilkan data komplain berdasarkan prioritas komplain tinggi ke sedang
2.Sistem menampilkan data komplain yang ber-status delegasi atau belum ditangani 3.Sistem menampilkan
nama tim berdasarkan id komplain dan
pendelegasian kepala bagian
Aktor memilih detil jenis produk yang dikomplain
Sistem menampilkan detil jenis produk (komponen / form) berdasarkan isi produk komplain yang diajukan
Aktor mengisi diskripsi kerusakan produk perlu diganti atau tidak
Sistem menampung data diskripsi kerusakan Aktor menekan tombol save 1.Sistem mencetak auto
increment perbaikan 2.Sistem menyimpan data
kerusakan produk sekaligus merubah status komplain menjadi Perbaikan
3.Sistem menampilkan komplain yang berstatus Delegasi
Akhir Deskripsi detil kerusakana software/hardware yang diganti atau bisa
diperbaiki
Non Fungsional Pencatatan produk dapat dilakukan apabila pendelegasian sesuai
dengan jobdesc Tim Perbaikan
4. Fungsi Penggantian Produk Level Software/Hardware
Tabel 3.7 Fungsi Penggantian Produk
Aktor Tim Perbaikan
Diskripsi Fungsi ini digunakan oleh tim perbaikan untuk melakukan
13
Pemicu Fungsi Pencatatan Kerusakan Produk
Awal Otentikasi (Tim Perbaikan)
Alur Normal Aksi Stakeholder Respon Sistem
Aktor memilih produk lama yang akan diganti
Sistem menampilkan data produk yang diambil dari
table software atau
hardware Aktor mengisi diskripsi nama produk
baru
Sistem menampung diskripsi nama produk baru
Aktor memilih nama tim untuk yang menangani produk
Sistem menampilkan nama tim berdasarkan produk
(software/hardware)
Aktor memilih nama bagian sebagai penempatan produk baru (hanya untuk produk hardware)
Sistem menampilkan data seluruh bagian pada semua departemen Aktor mengisi versi produk (hanya
untuk software)
Sistem menampung nama versi produk
Aktor mengisi diskripsi keterangan produk (hanya untuk software)
Sistem menampung diskripsi keterangan produk
Aktor menekan tombol save 1.Sistem mencetak auto increment produk baru 2.Sistem menyimpan
produk pada database sekaligus merubah status produk lama menjadi Tidak Aktif beserta detil produk (komponen / form) yang ada didalamnya 3.Sistem mengirim
notifikasi penggantian slesai
4.Sistem menampilkan detil data produk yang diganti
5.Sistem mengosongkan form penggantian
Akhir Data produk baru serta history produk (hardware/software)
Non Fungsional Permintaan penggantian produk hardware ditujukan kepada gudang
5. Fungsi Penggantian Produk Level Komponen/Form
Tabel 3.8 Fungsi Penggantian Produk
14
Diskripsi Fungsi ini digunakan oleh tim perbaikan untuk melakukan
penggantian produk yang telah rusak dan diganti dengan produk yang lain
Pemicu Fungsi Pencatatan Kerusakan Produk
Awal Otentikasi (Tim Perbaikan)
Alur Normal Aksi Stakeholder Respon Sistem
Aktor memilih produk lama yang akan diganti
Sistem menampilkan data produk yang diambil dari
table komponen / form
berdasarkan produk yang dipilih
Aktor mengisi nama komponen / form baru
Sistem menampung nama komponen atau form baru Aktor menekan tombol save 1.Sistem mencetak auto
increment komponen / form baru
2.Sistem menyimpan data perubahan produk sekaligus merubah status detil produk yang lama menjadi Tidak Aktif 3.Sistem merubah versi
nama produk yang lama dengan versi produk yang baru (software) 4.Sistem mengirim
notifikasi penggantian selesai
5.Sistem menampilkan detil data produk yang diganti
6.Sistem mengosongkan form penggantian
Akhir Detil komponen atau form yang sudah diganti
Non Fungsional Permintaan penggantian produk hardware ditujukan kepada gudang
6. Fungsi Perbaharui Perkembangan
Tabel 3.9 Fungsi Perbaharui Perkembangan
Aktor Tim Perbaikan
Diskripsi Fungsi ini digunakan oleh tim perbaikan untuk memperbaharui
perkembangan pengerjaan komplain
Pemicu Fungsi Penggantian Produk
Awal Otentikasi (Tim Perbaikan)
Alur Normal Aksi Stakeholder Respon Sistem
15
komplain berdasarkan status komplain Perbaikan Aktor mengisi diskripsi
perkembangan komplain
Sistem menampung diskripsi perkembangan Aktor memilih perbaikan selesai
apabila komplain sudah selesai
Sistem menampung nama perbaikan selesai
Aktor menekan tombol save 1.Sistem mencetak auto increment perkembangan 2.Sistem menyimpan data
perkembangan detil komplain sekaligus merubah status komplain menjadi Perbaikan Selesai (apabila komplain telah selesai diperbaiki)
3.Sistem mengirim notifikasi kepada unit eksternal (apabila komplain telah selesai) 4.Sistem mengosongkan
form perkembangan komplain
Akhir Data perkembangan penangan komplain
Non Fungsional Perbaharui perkembangan komplain dilakukan setiap selesai
melakukan perbaikan produk
7. Fungsi Penyelesaian Komplain
Tabel 3.10 Fungsi Penyelesaian Komplain
Aktor Unit eksternal
Diskripsi Fungsi ini digunakan oleh unit eksternal untuk mengubah dan
menutup status komplain dari perbaikan menjadi ditutup (selesai)
Pemicu Fungsi Perkembangan
Awal Otentikasi (Unit Eksternal), Notifikasi
Alur Normal Aksi Stakeholder Respon Sistem
Aktor memilih data komplain Sistem menampilkan data komplain dari Tim Perbaikan berdasarkan status perbaikan komplain selesai
Aktor merubah status komplain menjadi selesai atau Tidak Sesuai
Sistem menampung status komplain
Aktor mengisi diskripsi kesesuaian komplain
16
komplain sekaligus merubah komplain menjadi Selesai apabila komplain sesuai
2.Sistem menyimpan data komplain sekaligus merubah komplain menjadi Tidak Sesuai apabila komplain tidak sesuai dan mengirimkan notifikasi ke Tim Perbaikan
3.Sistem mengosongkan form penyelesaian
Akhir Data komplain yang telah ditutup/selesai
Non Fungsional Perbaharui status penyelesaian komplain hanya boleh dilakukan oleh
unit eksternal
3.1.2 Perencanaan
Pada tahap perencanaan dilakukan proses penjadwalan dari awal
melakukan observasi pada PT Petrokimia Gresik, kemudian proses wawancara
dengan beberapa karyawan Departemen Teknologi Informasi. Setelah melakukan
tahap tersebut, maka dapat disusun analisis bisnis yang selanjutnya peneliti
melakukan proses analisis kebutuhan pengguna dengan cara observasi dan
wawancara dengan beberapa karyawan PT Petrokimia Gresik yang akan
menggunakan website aplikasi. Kemudian proses selanjutnya yaitu, peneliti
memembuat analisis kebutuhan data dan analisis kebutuhan fungsi. Setelah itu,
peneliti melakukan perencanaan yang menghasilkan beberapa kebutuhan
perangkat keras dan perangkat lunak yang digunakan dalam pembuatan website
aplikasi. Setelah itu dilakukan proses pemodelan yang membahas tentang
perancangan arsitektur, perancangan proses, perancangan basis data, perancangan
antar muka dan perancangan pengujian. Setelah itu proses pengkodean dan
