TA : Rancang Bangun Aplikasi Penanganan Komplain Menggunakan Administrative Workflow System Pada PT Petrokimia Gresik.

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

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2016

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. Manajer, Kepala Bagian dan unit eksternal tidak bisa mengetahui perkembangan

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 perusahaan yaitu:

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 informasi pada penelitian ini.

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 bertambahnya kebutuhan bisnis dari perusahaan.

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 puasan konsumen terhadap proses penggunaan sumberdaya organisasi,

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 komplain, serta kemudahan bagi konsumen untuk menghubungi perusahaan.

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 Gambar 2.1 akan dijelaskan bagaimana sebuah kegiatan dipecah menjadi

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 tidak biasa, yang mengganggu lancarnya jalan dari sistem. Sistem mungkin

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) Struktur data yang memungkinkan program memanipulasi informasi secara

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 khusus oleh kontraktor perangkat lunak untuk pembeli tersebut.

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 mengembangkan sistem-sistem perangkat lunak sebelumnya. Hal tersebut tentu

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

Project iniiation Requirement

gathering

Planning

Estimating Scheduling Tracking

Modeling

Analysis Design

Deployment

Delivery Support Feedback

Construction

Code Test

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. Validasi adalah melihat kebenaran sistem apakah proses yang telah ditulisan

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) dikalikan total pengguna (Ptot). Nilai persentase akhir (Pre) diperoleh dari jumlah

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.1Analisis 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 observasi. Selain itu proses wawancara juga berfungsi untuk menanyakan

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 perkembangan dan dokumen penyelesaian.

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

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 informasi dan observasi pada lokasi di PT Petrokimia Gresik, didapatkan kondisi

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 untuk membaca data jabatan sebagai data tambahan untuk pembuatan aplikasi

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

Sistem memfilter seluruh notifikasi komplain berdasarkan tipe produk hardware masuk ke kepala bagian Tekop sedangkan

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

pencatatan komplain apakah hardware/software perlu diganti atau bisa diperbaiki

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

penggantian produk yang telah rusak dan diganti dengan produk yang lain

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

Sistem menampung diskripsi kesesuaian Aktor menekan tombol save 1.Sistem menyimpan data

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 pengujian aplikasi pada tahap konstruksi.

17

Untuk membuat website aplikasi ini dibutuhkan beberapa spesifikasi

perangkat keras dan perangkat lunak. Untuk perangkat keras dibutuhkan

processor core i3, memory RAM 2 Gb, hardisk 320 Gb, VGA 1 Gb, Monitor

dengan resolusi 1024 x 768, mouse, keyboard. Sedangkan untuk perangkat lunak

dibutuhkan Web Server XAMPP versi 1.7.7, Sql Server 2008, Google Chrome

atau Opera atau Web Browser lain dan Sistem Operasi Windows 7.

3.2 Perancangan Sistem

Berdasarkan hasil analisis yang sudah dibuat, maka dapat dilakukan perancangan sistem sebagai dasar pembuatan aplikasi penanganan komplain. Pada tahap perancangan sistem diawali dengan analisis kebutuhan pengguna, kemudian analisis kebutuhan perangkat lunak, perancangan arsitektur sistem, perancangan proses, perancangan basis data, perancangan antar muka dan perancangan uji coba.

3.2.1 Perancangan Arsitektur Sistem

Pada tahap ini dilakukan perancangan arsitektur dari sistem yang akan dibuat. Arsitektur pada aplikasi penanganan komplain menggunakan arsitektur

network atau web based. Pada arsitektur ini dijelaskan bahwa pengajuan komplain

oleh unit eksternal dilakukan melalui website aplikasi yang ditunjukkan pada

nomor satu gambar 3.1 kemudian akan diterima oleh kepala bagian pada nomor dua. Setelah kepala bagian menerima notifikasi pengajuan komplain dari unit

eksternal, maka kepala bagian melakukan proses delegasi pada website yang

ditunjukkan pada nomor tiga kemudian dikirimkan kepada tim perbaikan. Setelah tim perbaikan menerima notifikasi, tim harus selalu melakukan pembaharuan

18

perkembangan perbaikan ketika tim melakukan perbaikan. Apabila perbaikan tersebut sudah selesai, maka tim perbaikan mengirim notifikasi kepada unit

eksternal melalui website yang ditunjukkan pada nomor empat dan lima. Setelah

unit eksternal menerima notifikasi, maka unit eksternal melakukan konfirmasi dan penutupan komplain yang sudah diajukan. Dari sini, unit eksternal, kepala bagian, dan manajer juga dapat mengetahui perkembangan penanganan komplain dari

website aplikasi yang ditunjukkan pada nomor enam.

Unit Eksternal Dep. Produksi

Kepala Bagian Pengembangan Aplikasi

TIM Perbaikan

Hardware

Manajer TI

1 2

3

3 4

5 6 Unit Eksternal

Dep. Keuangan

Unit Eksternal Pelayanan Umum

Unit Eksternal Dep. Personalia Unit Eksternal

Dep. Kemitraan

Unit Eksternal Dep. TI

Kepala Bagian Teknik & Operasional

TIM Perbaikan

Software

Gambar 3.1 Arsitektur Sistem

3.2.2 Perancangan Proses

Pada tahap perancangan proses terdapat 3 proses yaitu merancang alur

proses bisnis, pembuatan context diagram dan data flow diagram. Kemudian dari

hasil analisis kebutuhan fungsi, terdapat 8 fungsi untuk membangun sistem berupa

aplikasi penanganan komplain. Dari 8 fungsi tersebut, peneliti menggambarkan

19

A Alur Proses Bisnis

Pada alur proses bisnis digambarkan dengan menggunakan BPMN. Berdasarkan permasalahan yang ada, peneliti membagi menjadi dua proses bisnis

yaitu alur proses komplain software dan alur proses komplain hardware.

1. Alur Proses Komplain Software

Untuk alur proses komplain software dimulai dari pengajuan komplain yang

dilakukan oleh unit eksternal kemudian mengirim notifikasi komplain kepada kepala bagian. Setelah menerima notifikasi, maka kepala bagian mendelegasian komplain kepada tim perbaikan. Setelah tim perbaikan menerima pendelegasian dari kepala bagian, maka tim melakukan perbaikan. Setelah dilakukan perbaikan, tim perbaikan mengirim notifikasi penyelesaian kepada unit eksternal. Setelah unit eksternal menerima notifikasi kmplain, unit eksternal melakukan konfirmasi kesesuaian komplain. Untuk melihat gambaran

BPMN alur proses komplain hardware dapat dilihat pada lampiran tiga.

2. Alur Proses Komplain Hardware

Pada alur proses komplain yang dijadikan panduan untuk pembuatan aplikasi

ini dimulai dari unit eksternal mengajukan komplain pada aplikasi website dan

mengirim notifikasi pengajuan komplain kepada kepala bagian. Setelah kepala

bagian menerima notifikasi komplain yang dapat dilihat pada website, maka

kepala bagian dapat melakukan pendelegasian kepada tim perbaikan sekaligus mengirim notifikasi pendelegasian. Setelah tim menerima pendelegasian tersebut, maka tim melakukan perbaikan komplain. Apabila pada komplain tersebut memerlukan penggantian produk, maka tim akan menghubungi pihak pengadaan barang untuk penggantian barang yang dikomplain. Setelah tim

20

mendapatkan pengganti barang dari pihak pengadaan, maka tim melakukan penggantian produk sekaligus mengirim notifikasi penyelesaian kepada unit eksternal. Setelah unit eksternal menerima notifikasi dari tim perbaikan, maka unit eksternal melakukan melakukan konfirmasi kesesuaian komplain. Untuk

melihat gambaran BPMN alur proses komplain hardware dapat dilihat pada

lampiran empat.

B Context Diagram

Context diagram dibuat untuk menampilkan entitas apa saja yang akan

berinteraksi dengan aplikasi penanganan komplain. Context diagram dibuat

berdasarkan hasil analisis kebutuhan fungsi. Dari hasil kebutuhan fungsi yang dibuat sebelumnya, maka dapat dihasilkan tiga aktor yaitu Unit Eksternal, Kepala

Bagian dan TIM. Berikut ini gambar Context Diagram Penanganan Komplain.

Entitas unit eksternal memberikan data pengajuan komplain berupa data diskripsi komplain serta produk yang dikomplain yang ditujukan kepada sistem, kemudian sistem meberi timbal balik berupa pemberitahuan pengajuan dapat tersimpan atau sebaliknya. Setelah sistem penyimpan data pengajuan komplain, selanjutnya sistem memberikan notifikasi kepada kepala bagian guna dapat mengetahui adanya komplain sekaligus dapat melakukan pendelegasian komplain kepada unit eksternal yang dikirim melalui sistem. Setelah sistem mendapat data pendelegasian, sistem meberikan timbal balik berupa pemberitahuan pendelegasian komplain dapat tersimpan atau sebaliknya. Setelah data pendelegasian disimpan oleh sistem, maka sistem akan memberikan notifikasi pendelegasian kepada tim. Kemudian tim memberikan data perbaikan kepada sistem sehingga sistem akan memberikan timbal balik berupa pemberitahuan

21

perbaikan dapat tersimpan atau tidak. Apabila komplain telah selesai diperbaiki,

maka tim melakukan update perbaikan ke sistem kemudian sistem akan

memberikan notifikasi kepada unit eksternal sebagai pemberitahuan bahwa komplain yang telah diajukan telah selesai.

konfirmasi kesesuaian

notifikasi penyelesaian

Notifikasi pendelegasian data pengajuan

notifikasi pengajuan komplain baru

pemberitahuan perbaikan

data perbaikan pemberitahuan pendelegasian

data pendelegasian pemberiitahuan status pengajuan komplain

0

AWS Komplain

+

Unit Eksternal Kepala

Bagian

TIM

Gambar 3.2 Context Diagram Penanganan Komplain

C Diagram Berjenjang

Diagram jenjang digunakan untuk menampilkan seluruh proses yang akan ditangani pada sistem yang akan dibangun. Sistem akan dibangun berdasarkan enam proses yaitu proses pengajuan komplain, proses pendelegasian komplain, proses pencatatan komplain, proses penggantian produk, proses perkembangan komplain dan yang terakhir yaitu proses penyelesaian komplain. Pada proses penggantian produk, dapat dibagi menjadi dua bagian yaitu

penggantian level produk hardware/software dan penggantian level

komponen/form. Diagram berjenjang dari sistem yang akan dibangun dapat dilihat

22

D Data Flow Diagram Level 0

Dalam pembuatan data flow diagram ini mengacu pada kebutuhan

fungsi. Pada kebutuhan fungsi terdapat 8 fungsi yang akan dipakai sebagai proses

pada data flow diagram level 0. Proses tersebut saling berhubungan satu sma lain

misalnya dari pengajuan komplain memberikan data komplain kemudian selanjutnya pendelegasian dan seterusnya. Untuk lebih jelas dapat dilihat pada gambar 3.4.

Proses pertama yaitu pengajuan komplain. Pada proses ini unit eksternal

memberikan data pengajuan kepada sistem yang diambil dari beberapa table yaitu

table hardware/software dan table pegawai. Kemudian sistem memberikan

informasi kepada unit eksternal apabila data tersebut dapat tersimpan atau tidak. Apabila data dapat tersimpan, maka sistem akan menyimpan data tersebut

kedalam table komplain dan memberikan notifikasi kepada kepala bagian.

Setelah data pengajuan selesai maka proses selanjutnya yaitu pendelegasian. Proses pendelegasian bermula dari data notifikasi yang diberikan oleh unit eksternal yang kemudian akan diproses oleh sistem. Kepala bagian

memberikan data pendelegsian kepada sistem yang diambil dari beberapa table

yaitu table hardware/software, table tim dan table komponen. Sistem akan

memberikan timbal balik berupa pemberitahuan bahwa pendelegasian berhasil disimpan atau tidak. Apabila data pendelegasian dapat disimpan, maka sistem

akan menyimpan kedalam table komp hardware atau komp software dan table

komplain. Kemudian sistem meberikan notifikasi kepada tim perbaikan.

Pada proses ketiga yaitu pencatatan kegiatan. Proses ini bermula dari notifikasi pendelegasian yang dikirim oleh sistem yang kemudian diterima oleh

23

tim perbaikan sehingga dapat mengetahui kerusakan yang diajukan oleh unit eksternal. Setelah tim mendapatkan data pendelegasian dari kepala bagian, tim perbakan memberikan data perbaikan kepada sistem yang diambil dari beberapa

table yaitu table hardware/software, table tim, table komplain dan table komp

hardware/komp software. Sistem akan memberikan timbal balik berupa

pemberitahuan data perbaikan dapat tersimpan atau tidak. Apabila data perbaikan

tersimpan maka sistem akan menyimpan kedalam table prog kompoenen atau

prog form dan table komplain.

Dari proses pencatatan dapat melakukan proses percabangan yaitu proses penggantian apabila produk perlu diganti dan proses perkembangan apabila proses tidak perlu diganti. Pada proses penggantian, tim memberikan data penggantian produk kepada sistem dan sistem akan memberikan timbal balik berupa pemberitahuan produk telah berhasil diganti atau tidak. Apabila produk berhasil

diganti maka produk akan meng-update table hardware atau software dan table

komponen atau form.

Setelah proses penggantian selesai, tim harus melakukan pembaharuan perkembangan komplain. Pada proses ini tim memberikan data perkembangan produk kepada sistem, kemudian sistem memberikan timbal balik berupa pemberitahuan data perkembangan dapat tersimpan atau tidak. Apabila data

perkembangan tersimpan, maka sistem akan menyimpan kedalan table prog

komponen atau prog form. Kemudian setelah proses perkembangan benar-benar

terselesaikan, maka tim dapat mengirim notifikasi kepada unit eksternal bahwa komplain telah selesai diperbaiki.

47

dengan menggunakan aplikasi penanganan komplain menjadi tiga menit tiga puluh tiga detik lebih cepat dari pada melakukan pencarian data komplain dengan manual. Tabel hasil perbandingan lama pencarian data komplain dapat dilihat pada lampiran 10.

Setelah dilakukan skenario uji sistem keseluruhan maka didapatkan empat variable untuk memudahkan manajer, kepala bagian dan unit eksternal dalam melakukan pemantauan data komplain. Variable tersebut yaitu pengumpulan data, kelengkapan data, pengkategorian data dan status komplain. Dari emapat variable tersebut, terdapat dua variable yang tidak bisa terpenuhi untuk memudahkan manajer, kepala bagian dan unit eksternal dalam melakukan pemantauan data komplain dengan manual. Variable tersebut yaitu pengkategorian data komplain dan status komplain. Namun pada aplikasi penanganan komplain, semua variable dapat terpenuhi sehingga manajer, kepala bagian dan unit eksternal dengan mudah dapat memantau data komplain.

Untuk memastikan kesesuaian alur sistem dengan prosedur yang ada maka dibuat empat skenario pengujian yaitu skenario komplain sesuai, skenario komplain tidak sesuai, skenario komplain kepada tim melalui telepon dan skenario komplain kepada kepala bagian melalui telepon. Dari empat skenario tersebut didapatkan hasil yang sesuai dengan harapan peneliti. Sehingga aplikasi sudah dapat dikatakan sesuai dengan prosedur yang ada. Tabel skenario kesesuaian sistem dengan prosedur dapat dilihat pada lampiran 11.

Pada pengujian pengguna, didapatkan 14 orang untuk melakukan uji coba aplikasi penanganan komplain. Pengguna tersebut yaitu unit eksternal, kepala bagian, tim perbaikan produk, ahli sistem dan manajer. Untuk uji coba

48

pengguna unit eksternal didapatkan nilai persentase akhir yaitu 82,5% dengan jumlah responden empat, untuk uji coba pengguna kepala bagian didapatkan nilai persentase akhir yaitu 83,3% dengan jumlah responden dua, untuk uji coba pengguna tim perbaikan produk didapatkan nilai persentase akhir yaitu 91,1% dengan jumlah responden enam, untuk uji coba ahli sistem didapatkan nilai prsrentase akhir yaitu 94,2% dengan jumlah responden satu dan uji coba manajer didapatkan persentase akhir yaitu 80% dengan jumlah responden satu.

Pengguna(n) = (jumlah responden x presentase akhir(n)) Pengguna Unit Ekternal = 4 x 82,5 = 330

Pengguna Kepala Bagian = 2 x 83,3 = 166,6

Pengguna Tim Perbaikan Produk = 6 x 91,1 = 546,6 Pengguna Ahli Sistem = 1 x 94,2 =94,2

Pengguna Manajer = 1 x 80 = 80 Jumlah Hasil Pengguna = 1217,4

Sehingga didapatkan rata-rata presentase akhir untuk uji coba pengguna yaitu (jumlah hasil pengguna / jumlah responden)

Presentase Akhir = 1217,4 / 14 = 86,95%

Nilai akhir yang berupa angka persentase menunjukkan nilai 86,95%.

Berdasarkan perhitungan presentase akhir dari semua pengguna, nilai tersebut berada di antara interval 81% dan 100% sehingga termasuk dalam kategori sangat baik.

1

BAB V

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Setelah melakukan rancang bangun aplikasi penanganan komplain ini, dapat disimpulkan beberapa hal sebagai berikut:

1. Dokumen komplain yang sudah distandarkan yaitu dokumen pengajuan, dokumen pendelegasian, dokumen perbaikan, dokumen penyelesaian dan dokumen perkembangan komplain yang sebelumnya tidak ada.

2. Aplikasi penanganan komplain dapat melakukan pencarian data komplain dengan rata-rata waktu tiga menit tiga puluh tiga detik lebih cepat dibanding pencarian manual. Dengan perolehan lima data komplain didapat pencarian manual membutuhkan rata-rata waktu tiga menit empat puluh delapan detik sedangkan untuk pencarian dengan aplikasi membutuhkan rata-rata waktu lima belas detik.

3. Aplikasi dapat memudahkan manajer, kepala bagian dan unit eksternal dalam memantau data komplain. Dibuktikan dengan aplikasi dapat memenuhi empat variable yang ditentukan dalam memantau data komplain sedangkan pemantauan manual hanya dapat memenuhi dua variable.

4. Aplikasi sudah berjalan sesuai dengan prosedur yang ada. Dibuktikan dengan empat skenario pengujian alur sistem pada aplikasi, bahwa skenario yang ditentukan didapatkan hasil yang sesuai dengan prosedur penanganan komplain.

2

5. Aplikasi penanganan komplain telah diuji coba oleh 14 responden karyawan PT Petrokimia Gresik dengan hasil 86,95%. Hal ini berarti aplikasi dapat dinyatakan layak untuk digunakan dan termasuk dalam kategori sangat baik.

5.2 Saran

Berikut adalah saran yang dapat diberikan untuk penelitian selanjutnya: 1. Penambahan sistem pendukung keputusan pada produk yang dikomplain

sehingga dapat membantu kepala bagian dalam menentukan pengadaan produk baru dan estimasi waktu dalam penyelesaian data komplain.

2. Penambahan sistem pengadaan, sehingga ketika komplain membutuhkan penggantian produk maka sistem akan terintegrasi dengan sistem pengadaan. 3. Notifikasi dapat ditambah berupa SMS Gateway.

DAFTAR PUSTAKA

Chaffey, D. 1998. Groupware, Workflow and intranets: reengineering the enterprise with collaborative Software. Amerika Srikat: Digital Press. Husein, U. 2003. Metode Riset Bisnis. Jakarta: Gramedia Pustaka Utama.

Kendall, K.E. dan Kendall, J.E. 2008. System Analysis and Design, Seventh Edition. New Jersey: Pearson Prentice Hall.

Kottler, P. 1997. Manajemen Pemasaran Jilid 2. Yogyakarta: Andi Offset.

Ombudsman, B. B. 2010. Effective Complaint Handling Guidelines, 2nd Edition. Sydney.

Pressman, R. S. 2012a. Rekayasa Perangkat Lunak: Pendekatan Praktisi Buku 1. Yogyakarta: Andi.

Pressman, R. S. 2012b. Software Engineering: A Practitioner’s Approach, Seventh Edition. Yogyakarta: ANDI.

Romeo. 2003. Testing dan Implementasi Sistem Edisi Pertama. Surabaya: STIKOM.

Riduwan. 2005. Skala Pengukuran Variabel-Variabel Penelitian, Cetakan Ketiga. Bandung: Alfabeta.

Simamarta, J. 2010. Rekayasa Web. Yogyakarta: Andi Offset.

Shelly, G.B. dan Vermalat, M.E. 2010. Discovering Computer 2010: Living in a Digital World, complete. Boston: Course Technology.

Sommerville, I. 2001. Software Engineering 6th Edition. Edinburgh Gate. England: Pearson Education Limited.

Suprapto, W. 2006. Pelayanan Publik dari Dominasi ke Partisipasi. Surabaya: Airlangga University Press.

Suyanto, M. 2005. Pengantar Teknologi Informasi untuk Bisnin. Yogyakarta: Andi.

Tjiptono, F. 2005. Pemasaran Jasa. Malang: Bayumedia Publishing.

Tjiptono, F. 2008. Service Management : Mewujudkan Layanan Prima. Yogyakarta: Andi Offset