TA : Rancang Bangun Aplikasi Service Advisor Pada Bengkel Mobil Berbasis Web (Studi Kasus Karunia Motor Surabaya).

Nama : Riko Syaogi Priyanggoro NIM : 07.41010.0183

Program : S1 (Strata Satu) Jurusan : Sistem Informasi

SEKOLAH TINGGI

MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA

2013

STIKOM

ix

Halaman

ABSTRAK ... vi

KATA PENGANTAR ... vii

DAFTAR ISI ... ix

DAFTAR TABEL ... xii

DAFTAR GAMBAR ... xv

DAFTAR LAMPIRAN ... xxiv

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 4

1.3 Pembatasan Masalah ... 5

1.4 Tujuan ... 5

1.5 Sistematika Penulisan ... 6

BAB II LANDASAN TEORI ... 8

2.1 Bengkel ... 8

2.1.1 Fasilitas ... 9

2.1.2 Skala Usaha ... 10

2.2 Sistem Pakar ... 11

2.2.1 Komponen Sistem Pakar ... 14

2.2.2 Forward Chaining ... 15

2.2.3 Backward Chaining ... 16

2.2.4 Verifikasi ... 17

STIKOM

x

2.3 Rekayasa Perangkat Lunak ... 22

2.3.1 Proses Perangkat Lunak ... 23

2.3.2 Model Perangkat Lunak ... 24

2.4 Sistem Basis Data ... 25

2.4.1 Komponen Basis Data ... 26

2.5 Web Developer ... 28

2.5.1 Unsur - Unsur Dalam Penyediaan Website atau Situs .... 29

2.5.2 Intranet ... 31

2.6 Testing dan Implemententasi ... 34

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 36

3.1 Analisis Sistem ... 36

3.2 Perancangan Sistem ... 37

3.2.1 Diagram Blok Aplikasi Service Advisor ... 38

3.2.2 Diagram Blok Sistem Pakar ... 45

3.2.3 Dependency Diagram ... 46

3.2.4 Arsitektur Sistem ... 52

3.2.4 Data Flow Diagram (DFD) ... 55

3.2.5 Entity Relationship Diagram (ERD) ... 62

3.2.6 Struktur Tabel ... 65

3.2.7 Perancangan Input / Output ... 75

STIKOM

xi

BAB IV IMPLEMENTASI DAN EVALUASI ... 104

4.1 Implementasi Sistem ... 104

4.1.1 Halaman Akses Admin ... 108

4.2.2 Halaman Akses Pakar ... 119

4.2.3 Halaman Akses Service Advisor ... 123

4.2.4 Halaman Akses Gudang ... 129

4.2.5 Halaman Akses Kasir ... 129

4.2.6 Halaman Akses Kepala Bengkel ... 130

4.2 Evaluasi Sistem ... 134

4.2.1 Uji Coba ... 134

4.2.2 Pembahasan ... 162

BAB V KESIMPULAN ... 165

5.1 Kesimpulan ... 165

5.2 Saran ... 166

DAFTAR PUSTAKA ... 167

LAMPIRAN ... 168

STIKOM

xii

Tabel 2.2 Reduced Decision Table ... 22

Tabel 3.1 Rule Set Dalam Decision Table ... 40

Tabel 3.2 Complete Decision Table Rule Set 4 ... 50

Tabel 3.3 Reduced Decision Table Rule Set 4 ... 51

Tabel 3.4 Tabel Pegawai ... 65

Tabel 3.5 Tabel Pelanggan ... 65

Tabel 3.6 Tabel Mobil Pelanggan ... 66

Tabel 3.7 Tabel Master Mobil ... 66

Tabel 3.8 Tabel Suku Cadang ... 67

Tabel 3.9 Tabel Detail Suku Cadang ... 67

Tabel 3.10 Tabel Pekerjaan ... 68

Tabel 3.11 Tabel Kategori Pekerjaan ... 68

Tabel 3.12 Tabel Harga Pekerjaan ... 69

Tabel 3.13 Tabel Estimasi Suku Cadang ... 69

Tabel 3.14 Tabel Transaksi ... 70

Tabel 3.15 Tabel Detail Suku Cadang Transaksi ... 70

Tabel 3.16 Tabel Detail Pekerjaan Transaksi ... 71

Tabel 3.17 Tabel Kategori Kerusakan ... 71

Tabel 3.18 Tabel Rule ... 71

Tabel 3.19 Tabel Detail Rule ... 72

STIKOM

xiii

Tabel 3.21 Tabel Detail Diagnosa ... 73

Tabel 3.22 Tabel Hasil Diagnosa ... 73

Tabel 3.23 Tabel Parameter ... 74

Tabel 3.24 Tabel Possible Value ... 74

Tabel 3.25 Tabel Syncronisasi Pekerjaan ... 75

Tabel 3.26 Desain Test Case Manipulasi Fitur Master Pegawai ... 97

Tabel 3.26 Desain Test Case Manipulasi Fitur Master Pegawai (lanjutan) .... 98

Tabel 3.27 Desain Test Case Manipulasi Fitur Master Pekerjaan ... 99

Tabel 3.28 Desain Test Case Manipulasi Fitur Master Suku Cadang ... 100

Tabel 3.29 Desain Test Case Manipulasi Fitur Laporan Transaksi ... 100

Tabel 3.30 Desain Test Case Manipulasi Fitur Laporan Loyalitas Pelanggan .. 101

Tabel 3.31 Desain Test Case Manipulasi Fitur Laporan Beban Kerja Mekanik ... 101

Tabel 3.32 Desain Test Case Manipulasi Fitur Laporan Pembelian Suku Cadang ... 102

Tabel 3.33 Desain Test Case Manipulasi Fitur Laporan Stock Suku Cadang ... 102

Tabel 3.34 Desain Test Case Diagnosa Kerusakan Mesin ... 103

Tabel 3.35 Desain Test Case Kompatibilitas Aplikasi ... 103

Tabel 4.1 Data Pegawai ... 134

Tabel 4.2 Test Case Halaman Master Pegawai untuk Posisi Admin ... 135

Tabel 4.3 Data Pekerjaan ... 136

Tabel 4.4 Test Case Halaman Master Pekerjaan ... 137

STIKOM

xiv

Tabel 4.8 Test Case Halaman Diagnosa ... 143

Tabel 4.9 Test Case Halaman Detail Diagnosa ... 144

Tabel 4.10 Test Case Halaman Detail Service ... 146

Tabel 4.11 Test Case Halaman Daftar Service ... 148

Tabel 4.12 Test Case Halaman Kasir ... 149

Tabel 4.13 Test Case Halaman Laporan Transaksi ... 150

Tabel 4.14 Test Case Halaman Laporan Loyalitas Pelanggan ... 151

Tabel 4.15 Test Case Halaman Laporan Beban Kerja Mekanik ... 152

Tabel 4.16 Test Case Halaman Laporan Pembelian Suku Cadang ... 153

Tabel 4.17 Test Case Halaman Laporan Stock Suku Cadang ... 154

Tabel 4.18 Test Case Diagnosa Kerusakan Mesin ... 155

Tabel 4.19 Daftar Proses yang Diujikan ... 160

Tabel 4.20 Test Case Uji Coba Kompatibilitas Aplikasi ... 161

Tabel 4.21 Hasil Uji Coba Proses ... 161

STIKOM

xv

Halaman

Gambar 2.1 Struktur dasar sistem pakar (Irawan, 2007: 7) ... 14

Gambar 2.2 Forward Chaining (Kusrini, 2006:36) ... 16

Gambar 2.3 Backward Chaining (Kusrini, 2006:37) ... 16

Gambar 2.4 Dependency Diagram (Dologite, 1993:23) ... 20

Gambar 2.5 Penentuan Jumlah Rule (Dologite, 1993:24) ... 21

Gambar 2.6 Aliran hardware dan logik dalam Intranet ... 33

Gambar 3.1 Diagram Blok Aplikasi Service Advisor ... 38

Gambar 3.2 Rule Set Dalam Dependency Diagram ... 39

Gambar 3.3 Diagram Blok Diagnosa Kerusakan Mesin ... 46

Gambar 3.4 Dependency Diagram Diagnosa Kerusakan Mesin ... 47

Gambar 3.5 Dependency Diagram Diagnosa Kerusakan Transmisi ... 48

Gambar 3.6 Dependency DiagramDiagnosa Kerusakan Gardan ... 48

Gambar 3.7 Dependency Diagram Diagnosa Kerusakan Propeller Shaft .. 48

Gambar 3.8 Dependency Diagram Diagnosa Kerusakan Ban ... 48

Gambar 3.9 Dependency DiagramDiagnosa Kerusakan Rem ... 49

Gambar 3.10 Dependency DiagramDiagnosa Kerusakan Shock Breaker ... 49

Gambar 3.11 Dependency DiagramDiagnosa Kerusakan Setir ... 49

Gambar 3.12 Gambaran Umum Sistem Cerdas Service Advisor pada Bengkel Mobil Berbasis Web ... 52

Gambar 3.13 DFD Context Diagram ... 55

STIKOM

xvi

Gambar 3.16 DFD Level 1 Proses Pembuatan Laporan ... 60

Gambar 3.17 DFD Level 2 Proses Maintenance Sistem Pakar ... 61

Gambar 3.18 Conceptual Data Model (CDM) ... 63

Gambar 3.19 Physical Data Model (PDM) ... 64

Gambar 3.20 Desain Halaman Master Pegawai ... 76

Gambar 3.21 Desain Halaman Tambah Master Pegawai ... 76

Gambar 3.22 Desain Halaman Rubah Master Pegawai ... 77

Gambar 3.23 Desain Halaman Hapus Master Pegawai ... 77

Gambar 3.24 Desain Halaman Master Pekerjaan ... 78

Gambar 3.25 Desain Halaman Tambah Master Pekerjaan ... 78

Gambar 3.26 Desain Halaman Rubah Master Pekerjaan ... 79

Gambar 3.27 Desain Halaman Hapus Master Pekerjaan ... 79

Gambar 3.28 Desain Halaman Master Suku Cadang ... 80

Gambar 3.29 Desain Halaman Tambah Master Suku Cadang ... 80

Gambar 3.30 Desain Halaman Rubah Master Suku Cadang ... 81

Gambar 3.31 Desain Halaman Hapus Master Suku Cadang ... 81

Gambar 3.32 Desain Halaman Master Mobil Pelanggan ... 82

Gambar 3.33 Desain Halaman Rubah Master Mobil Pelanggan ... 82

Gambar 3.34 Desain Halaman Rubah Master Pelanggan ... 83

Gambar 3.35 Desain Halaman Hapus Master Mobil Pelanggan ... 83

STIKOM

xvii

Gambar 3.37 Desain Halaman Tambah Parameter ... 84

Gambar 3.38 Desain Halaman Edit Parameter ... 85

Gambar 3.39 Desain Halaman Tambah Possible Value ... 85

Gambar 3.40 Desain Halaman Rubah possible Value ... 86

Gambar 3.41 Desain Halaman generate Rule ... 86

Gambar 3.42 Desain Halaman Transaksi Baru ... 87

Gambar 3.43 Desain Halaman Tambah Data ... 87

Gambar 3.44 Desain Halaman Diagnosa ... 88

Gambar 3.45 Desain Halaman Hasil Diagnosa ... 88

Gambar 3.46 Desain Halaman Detail Service ... 90

Gambar 3.47 Desain Halaman Tambah Pekerjaan Service ... 90

Gambar 3.48 Desain Halaman Tambah Suku Cadang Service ... 91

Gambar 3.49 Desain Halaman Daftar Service ... 91

Gambar 3.50 D44ain Halaman Kasir ... 92

Gambar 3.51 Desain Nota ... 92

Gambar 3.52 Desain Halaman Daftar Suku Cadang Service ... 93

Gambar 3.53 Desain Halaman Laporan Transaksi ... 93

Gambar 3.54 Desain Halaman Laporan Beban Kerja Mekanik ... 94

Gambar 3.55 Desain Halaman Laporan Loyalitas Pelanggan ... 95

Gambar 3.56 Desain Halaman laporan Pembelian Suku Cadang ... 95

Gambar 3.57 Desain Halaman Laporan Stock Suku Cadang ... 96

Gambar 4.1 Halaman Master Pegawai ... 109

STIKOM

xviii

Gambar 4.5 Halaman Master Pekerjaan ... 111

Gambar 4.6 Halaman Tambah Pekerjaan ... 111

Gambar 4.7 Halaman Rubah Pekerjaan ... 112

Gambar 4.8 Konfirmasi Hapus Data Pekerjaan ... 112

Gambar 4.9 Halaman Daftar Harga Pekerjaan ... 113

Gambar 4.10 Halaman Isi Harga Pekerjaan ... 113

Gambar 4.11 Halaman Master Suku Cadang ... 114

Gambar 4.12 Halaman Tambah Suku Cadang ... 114

Gambar 4.13 Halaman Rubah Suku Cadang ... 115

Gambar 4.14 Konfirmasi Hapus Suku Cadang ... 115

Gambar 4.15 Halaman Daftar Suku Cadang per-Mobil ... 116

Gambar 4.16 Halaman Tambah Suku Cadang per-Mobil ... 116

Gambar 4.17 Halaman Mobil Pelanggan ... 117

Gambar 4.18 Halaman Info Pemilik ... 118

Gambar 4.19 Halaman Rubah Mobil ... 118

Gambar 4.20 Konfirmasi Hapus Mobil Pelanggan ... 119

Gambar 4.21 Halaman Sistem Pakar ... 120

Gambar 4.22 Halaman Tambah Parameter ... 121

Gambar 4.23 Halaman Edit Parameter ... 121

Gambar 4.24 Halaman Tambah Nilai (Possible Value) ... 122

STIKOM

xix

Gambar 4.26 Halaman Generate Rule ... 123

Gambar 4.27 Halaman Transaksi Baru ... 124

Gambar 4.28 Halaman Tambah Data Mobil Pelanggan ... 124

Gambar 4.29 Halaman Data Telah Ditemukan ... 125

Gambar 4.30 Halaman Diagnosa ... 125

Gambar 4.31 Tombol Proses Halaman Diagnosa ... 126

Gambar 4.32 Halaman Detail Diagnosa ... 126

Gambar 4.33 Tombol Proses Halaman Detail Diagnosa ... 126

Gambar 4.34 Halaman Detail Service ... 127

Gambar 4.35 Halaman Tambah Pekerjaan ... 127

Gambar 4.36 Halaman Tambah Suku Cadang ... 128

Gambar 4.37 Halaman Daftar Service ... 128

Gambar 4.38 Halaman Daftar Suku Cadang Service ... 129

Gambar 4.39 Halaman Daftar Service Selesai ... 130

Gambar 4.40 Nota ... 130

Gambar 4.41 Halaman Laporan Transaksi ... 131

Gambar 4.42 Halaman Laporan Beban Kerja Mekanik ... 132

Gambar 4.43 Halaman Laporan Loyalitas Pelanggan ... 132

Gambar 4.44 Halaman Laporan Pembelian Suku Cadang ... 133

Gambar 4.45 Halaman Laporan Stock Suku Cadang ... 133

Gambar 4.46 Hasil Test Case 1 “Mengetahui respon sistem ketika data pegawai ditambahkan.” – Halaman Pegawai untuk Posisi Admin ... 135

STIKOM

xx

pencarian data pegawai.” – Halaman Pegawai untuk Posisi

Admin ... 136 Gambar 4.49 Hasil Test Case 4 “Mengetahui respon sistem ketika data pegawai

dihapus.” – Halaman Pegawai untuk Posisi Admin ... 136 Gambar 4.50 Hasil Test Case 5 “Mengetahui respon sistem ketika data pekerjaan

ditambahkan.” – Halaman Pekerjaan untuk Posisi Admin ... 137 Gambar 4.51 Hasil Test Case 6 “Mengetahui respon sistem ketika data pekerjaan

dirubah.” – Halaman Pekerjaan untuk Posisi Admin ... 138 Gambar 4.52 Hasil Test Case 7 “Mengetahui respon sistem ketika melakukan pencarian data pekerjaan.” – Halaman Pekerjaan untuk Posisi Admin ... 138 Gambar 4.53 Hasil Test Case 8 “Mengetahui respon sistem ketika data pekerjaan

dihapus.” – Halaman Pekerjaan untuk Posisi Admin ... 138 Gambar 4.54 Hasil Test Case 9 “Mengetahui respon sistem ketika data suku

cadang ditambahkan.” – Halaman Suku Cadang untuk Posisi

Admin ... 140 Gambar 4.55 Hasil Test Case 10 “Mengetahui respon sistem ketika data suku

cadang dirubah.” – Halaman Suku Cadang untuk Posisi

Admin ... 140

STIKOM

xxi

pencarian data suku cadang.” – Halaman Suku Cadang untuk Posisi Admin ... 140 Gambar 4.57 Hasil Test Case 12 “Mengetahui respon sistem ketika data suku

cadang dihapus.” – Halaman Suku Cadang untuk Posisi

Admin ... 140 Gambar 4.58 Hasil Test Case 13 “Mengetahui respon sistem ketika data mobil &

pelanggan ditambah.” – Halaman Transaksi Baru untuk Posisi SA ... 141 Gambar 4.59 Hasil Test Case 14 “Mengetahui respon sistem ketika melakukan pencarian data mobil & pelanggan.” – Halaman Transaksi Baru untuk Posisi SA ... 142 Gambar 4.60 Hasil Test Case 15 “Mengetahui respon sistem ketika melakukan perpindahan ke halaman diagnosa.” – Halaman Transaksi Baru untuk Posisi SA ... 142 Gambar 4.61 Hasil Test Case 16 “Mengetahui respon sistem ketika berpindah ke halaman diagnosa.” – Halaman Diagnosa untuk Posisi SA ... 143 Gambar 4.62 Hasil Test Case 17 “Mengetahui respon sistem ketika melakukan perpindahan ke halaman detail diagnosa.” – Halaman Diagnosa untuk Posisi SA ... 144 Gambar 4.63 Hasil Test Case 18 “Mengetahui hasil dari keluhan pelanggan yang sudah dimasukkan pada halaman diagnosa.” – Halaman Detail Diagnosa untuk Posisi SA ... 145

STIKOM

xxii

Gambar 4.65 Hasil Test Case 20 “Kesimpulan dari keluhan pelanggan muncul pada tabel pekerjaan.” – Halaman Detail Service untuk Posisi SA ... 147 Gambar 4.66 Hasil Test Case 21 “Estimasi suku cadang yang harus diganti, estimasi waktu pengerjaan & estimasi total biaya muncul..” – Halaman Detail Service untuk Posisi SA ... 148 Gambar 4.67 Hasil Test Case 22 “Mengetahui respon sistem ketika data pekerjaan service ditambah.” – Halaman Detail Service untuk Posisi SA ... 148 Gambar 4.68 Hasil Test Case 23 “Mengetahui respon sistem ketika data suku cadang service ditambah.” – Halaman Detail Service untuk Posisi SA ... 149 Gambar 4.69 Hasil Test Case 24 “Melihat daftar mobil yang sedang diservis.” –

Halaman Daftar Service untuk Posisi SA ... 149 Gambar 4.70 Hasil Test Case 25 “Merubah status mobil.” – Halaman Daftar Service untuk Posisi SA ... 149 Gambar 4.71 Hasil Test Case 26 “Melihat daftar mobil berstatus Service Selesai.” – Halaman Kasir untuk Posisi Kasir ... 150

STIKOM

xxiii

tertentu.” – Halaman Laporan Transaksi untuk Posisi Kepala

Bengkel ... 151

Gambar 4.73 Hasil Test Case 28 “Menampilkan data jumlah pelanggan yang melakukan service pada kurun waktu tertentu.” – Halaman Laporan Loyalitas Pelanggan untuk Posisi Kepala Bengkel ... 152

Gambar 4.74 Hasil Test Case 29 “Menampilkan data jumlah waktu total mekanik melakukan service pada kurun waktu tertentu.” – Halaman Laporan Beban Kerja Mekanik untuk Posisi Kepala Bengkel ... 153

Gambar 4.75 Hasil Test Case 30 “Menampilkan data jumlah waktu total mekanik melakukan service pada kurun waktu tertentu.” – Halaman Laporan Beban Kerja Mekanik untuk Posisi Kepala Bengkel ... 154

Gambar 4.76 Hasil Test Case 31 “Menampilkan data stock suku cadang berdasarkan batas minimum.” – Halaman Laporan Stock Suku Cadang untuk Posisi Kepala Bengkel ... 154

Gambar 4.77 Rule Set 5 Diagnosa Carburator ... 158

Gambar 4.78 Rule Set 4 Diagnosa Penyalaan ... 158

Gambar 4.79 Rule Set 3 Diagnosa Kerusakan Saat Mesin Bisa Hidup ... 158

Gambar 4.80 Rule Set 2 Diagnosa Kerusakan Saat Mesin Tidak Bisa Hidup ... 159

Gambar 4.81 Rule Set 1 Diagnosa Kerusakan Mesin, Penyalaan & Tarikan ... 159

Gambar 4.82 Hasil Test Case 32 “Mengetahui hasil diagnosa.” ... 160

STIKOM

xxiv

Lampiran 2 Decision Table berdasarkan Rule Set masing-masing kategori kerusakan ... 171 Lampiran 3 Langkah – langkah agar tablet pc bisa mengakses localhost

Server ... 178 Lampiran 4 Daftar Harga Jasa ... 183

STIKOM

vi

Perusahaan bengkel mobil resmi mempunyai mempunyai seorang pegawai yang berhubungan dengan pelanggan mulai dari penerimaan mobil sampai penyerahan mobil, pegawai ini biasa disebut dengan Service Advisor. Salah satu tugas Service Advisor adalah memberikan diagnosa pekerjaan terhadap mobil yang akan diservis berdasarkan keluhan dari pelanggan. Sehingga ini akan menjadi masalah jika Service Advisor salah dalam mendiagnosa, dan akan lebih buruk lagi jika Service Advisor berhalangan hadir.

Untuk mengatasi masalah tersebut adalah dengan membuat aplikasi yang dapat menentukan pekerjaan yang harus diberikan, informasi suku cadang yang perlu diganti serta pemberian estimasi waktu dan biaya layaknya seorang Service

Advisor. Aplikasi ini juga dimaksudkan supaya bisa menjadi standar dalam

mendiagnosa, sehingga dapat mendukung keputusan Service Advisor dalam membuat diagnosa. Dalam menentukan pekerjaan yang harus diberikan, aplikasi ini akan menggunakan sistem pakar dengan metode pencarian forward chaining.

Dari hasil uji coba yang telah dilakukan, aplikasi ini dapat menentukan pekerjaan yang akan diberikan pada mobil berdasarkan keluhan-keluhan pelanggan dengan menggunakan sistem pakar. Aplikasi ini juga mampu memberikan estimasi suku cadang yang dibutuhkan, serta estimasi biaya & waktu. Selain itu aplikasi ini mampu mengolah data estimasi tersebut ke dalam sistem transaksi bengkel untuk pembuatan laporan-laporan yang dibutuhkan.

Kata kunci: Service Advisor, Bengkel Mobil, Sistem Pakar, Forward Chaining

STIKOM

1

1.1.Latar Belakang Masalah

Dari waktu ke waktu, kepadatan jalan raya mulai terlihat sangat mencolok. Hal ini dapat dibuktikan jika mengacu pada statistik perkembangan jumlah kendaraan bermotor dari Badan Pusat Statistik yang semakin tahun semakin meningkat, khususnya mobil penumpang yang pada tahun 2011 yang mencapai 9.548.866 kendaraan. Meskipun pemerintah telah melakukan perbaikan jalan, pelebaran jalan, dan pembangunan jalan bebas hambatan namun tetap saja kemacetan terjadi dimana-mana, terlebih lagi di kota-kota besar seperti Jakarta, Bandung dan Surabaya. Meningkatnya jumlah kendaraan bermotor diikuti dengan bertambahnya merek dan jenis kendaraan baru, ini tentu menjadi salah satu faktor penyebab perkembangan dunia otomotif di Indonesia dan mencerminkan semakin maraknya persaingan dalam dunia otomotif. Persaingan ini tidak hanya terjadi dalam bidang penjualan, tetapi juga dalam bidang pelayanan jasa yang meliputi bengkel-bengkel perawatan atau perbaikan.

Seperti para penjual, para penyedia pelayanan jasa juga terlibat dalam persaingan yang ketat. Perusahaan yang memberikan pelayanan berkualitas tinggi tidak diragukan lagi akan mengungguli pesaingnya yang kurang berorientasi pada pelayanan. Definisi dari kualitas pelayanan (jasa) sendiri adalah tingkat keunggulan yang diharapkan dan pengendalian atas tingkat keunggulan tersebut untuk memenuhi keinginan pelanggan. Dengan demikian ada 2 faktor utama yang

STIKOM

mempengaruhi kualitas pelayanan (jasa), yaitu : expected service dan perceived

Service.Apabila pelayanan (jasa) yang diterima atau dirasakan (perceived

service) sesuai dengan yang diharapkan (expected service), maka kualitas

pelayanan (jasa) dipersepsikan baik dan memuaskan. Jika pelayanan (jasa) yang diterima melampaui harapan pelanggan, maka kualitas pelayanan (jasa) dipersepsikan sebagai kualitas yang ideal. Sebaliknya jika pelayanan (jasa) yang di terima lebih rendah daripada yang di harapkan, maka kualitas pelayanan (jasa) dipersepsikan buruk. Maka, baik tidaknya kualitas pelayanan (jasa) tergantung pada penyedia pelayanan (jasa) dalam memenuhi harapan pelanggannya secara konsisten (Zeithaml dan Bitner, 2002).

Dalam perusahaan bengkel, yang mempunyai tugas utama untuk dapat memenuhi harapan pelanggan dengan memberikan kenyamanan dan kebutuhan pelanggan adalah Service Advisor (SA), karena SA yang sepenuhnya berhubungan dengan pelanggan mulai dari penerimaan mobil yang akan diservis sampai dengan penyerahan mobil yang sudah selesai diservis.

Salah satu tugas SA adalah bertugas untuk menerima pelanggan. Menerima pelanggan, dalam arti menerima keluhan-keluhan pelanggan dan memberikan informasi-informasi mengenai tindakan apa yang harus dilakukan kepada mobil pelanggan. Dari keluhan pelanggan, SA akan menentukan tindakan / pekerjaan yang harus dilakukan pada mobil, estimasi suku cadang yang perlu diganti, estimasi waktu pengerjaan, serta estimasi biaya keseluruhan service. Oleh karena itu, perusahaan bengkel sangat bergantung pada SA, karena jika SA tidak

STIKOM

ada bengkel akan kesulitan menentukan estimasi awal. Begitu juga yang terjadi pada Karunia Motor.

Karunia Motor merupakan salah satu perusahaan yang berperan di bidang otomotif. Karunia Motor yang bertempat di Jl. Sulawesi 47 Gubeng, Surabaya ini telah berdiri sejak tahun 1987. Selain sebagai dealer resmi (Authorized Dealer) yang menjual mobil-mobil bermerek Daihatsu, Karunia Motor juga menyediakan fasilitas pelayanan jasa bengkel resmi.

Karunia Motor mempunyai beberapa standar pelayanan, yaitu Booking / perjanjian, penerimaan, penulisan perintah kerja, memonitor perkembangan pekerjaan, pemeriksaan akhir, penyerahan dan follow-up, yang standar pelayanan tersebut ditujukan untuk memberikan pelayanan terbaik terhadap pelanggan. Hampir ke semua standar pelayanan tersebut dilakukan oleh SA, oleh karena itu Karunia Motor sangat bergantung pada SA, khususnya dalam tugasnya pada proses penulisan perintah kerja.

Pada Karunia Motor, di dalam proses penulisan perintah kerja ada 3 subproses yang harus ada yaitu mencatat keluhan pelanggan, memberikan informasi estimasi biaya dan waktu, serta memberikan penjelasan pekerjaan yang akan dilakukan dan persetujuan dari pelanggan. Semua proses tersebut dilakukan oleh SA. Maka dari itu, agar bengkel masih dapat berjalan dengan baik meski SA berhalangan hadir, bengkel harus mempunyai aplikasi yang dapat menggantikan SA dalam hal pencatatan keluhan pelanggan, penentuan tindakan / pekerjaan yang harus dilakukan, informasi suku cadang yang perlu diganti serta pemberian

STIKOM

estimasi waktu dan biaya. Aplikasi ini juga dimaksudkan agar bisa menjadi standar dalam mendiagnosa, sehingga bisa mendukung keputusan SA dalam membuat diagnosa. Agar dapat melakukan penentuan tindakan / pekerjaan yang harus dilakukan, aplikasi ini akan menggunakan sistem pakar dengan metode pencarian forward chaining.

Berdasarkan uraian di atas, penulis merasa tertarik untuk membuat sistem cerdas yang mampu menggantikan ataupun membantu Service Advisor pada bengkel mobil, yang penulis tuangkan dalam bentuk tugas akhir dengan judul :

“Rancang Bangun Aplikasi Service Advisor pada Bengkel Mobil Berbasis Web. (Studi Kasus Karunia Motor Surabaya)”

1.2. Perumusan Masalah

Berdasarkan latar belakang diatas dapat disimpulkan permasalahannya sebagai berikut :

1. Bagaimana merancang bangun aplikasi sistem pakar yang dapat menentukan tindakan / pekerjaan yang harus dilakukan pada mobil, estimasi suku cadang yang diperlukan, estimasi waktu pengerjaan, serta estimasi biaya yang dibutuhkan berdasarkan keluhan pelanggan bengkel.

2. Bagaimana merancang bangun aplikasi bengkel yang mampu mengolah data pekerjaan yang harus dilakukan dan suku cadang yang diperlukan ke dalam sistem transaksi bengkel untuk kepentingan pembuatan laporan-laporan yang dibutuhkan.

STIKOM

1.3. Pembatasan Masalah

Dalam penyusunan tugas akhir ini, didapatkan batasan-batasan masalah sebagai berikut :

1. Fokus utama pengerjaan aplikasi ini ada pada sistem pakar, sistem bengkel hanya sebagai pelengkap sehingga tidak detail.

2. Representasi pengetahuan yang digunakan adalah berbasis rule menggunakan metode pencarian forward chaining.

3. Rule sistem pakar hanya dapat digunakan pada mobil dengan transmisi manual, mobil berbahan bakar bensin, dan pada jenis - jenis mobil secara umum.

4. Tidak membahas mengenai proses penjualan dan pengadaan suku cadang.

5. Tidak menghitung laba-rugi bengkel.

6. Bahasa pemrograman yang dipakai berbasis PHP dengan menggunakan database MySQL.

1.4. Tujuan

Sesuai dengan permasalahan yang ada, tujuan dari pembuatan aplikasi ini adalah sebagai berikut :

1. Menghasilkan aplikasi sistem pakar yang dapat menentukan tindakan / pekerjaan yang harus dilakukan pada mobil, estimasi suku cadang yang diperlukan, estimasi waktu pengerjaan, serta estimasi biaya yang dibutuhkan berdasarkan keluhan pelanggan bengkel.

STIKOM

2. Menghasilkan aplikasi bengkel yang mampu mengolah data pekerjaan yang harus dilakukan pada mobil dan suku cadang yang diperlukan ke dalam sistem transaksi bengkel untuk kepentingan pembuatan laporan-laporan yang dibutuhkan.

1.5. Sistematika Penulisan

Penulisan Tugas Akhir ini secara sistematika diatur dan disusun dalam lima bab, yaitu:

Bab I Pendahuluan

Bab ini berisi tentang latar belakang masalah diambilnya topik Tugas Akhir, rumusan masalah dari topik Tugas Akhir, batasan masalah atau ruang lingkup pengerjaan Tugas Akhir, tujuan yang ingin dicapai dari Tugas Akhir yang dibuat, serta sistematika penulisan laporan Tugas Akhir.

Bab II Landasan Teori

Bab ini menjelaskan landasan teori yang berbentuk uraian kualitatif dan model sistematik yang langsung berkaitan dengan permasalahan yang dikerjakan. Dalam hal ini, teori yang digunakan dalam penyelesaian Tugas Akhir ini adalah teori tentang Definisi Bengkel (meliputi Bengkel Dealer, Bengkel Pelayanan Umum, Bengkel Pelayanan Khusus, Bengkel Unit Keliling, Bengkel besar, dan Bengkel Kecil), Sistem Pakar (meliputi Komponen Sistem Pakar, Forward Chaining, Backward Chaining, Verifikasi, Dependency Diagram, Decision Table, dan Reduced Decision Table), Rekayasa Perangkat Lunak (meliputi Proses Perangkat Lunak, dan Model Proses Perangkat Lunak), Sistem Basis Data (meliputi

STIKOM

Komponen Basis Data), Web Developer (meliputi Unsur-unsur dalam website, dan Intranet), Testing dan Implementasi.

Bab III Perancangan Sistem

Dalam bab ini dijelaskan tentang arsitektur aplikasi, dan dilanjutkan dengan penjelasan tentang Diagram Blok, Dependency Diagram, DFD, ERD, serta pembuatan desain input / output aplikasi.

Bab IV Implementasi dan Evaluasi

Dalam bab ini dijelaskan tentang implementasi dari aplikasi yang dibuat, rancangan input / output, pengujian terhadap aplikasi untuk mengetahui apakah aplikasi dapat berfungsi sesuai dengan yang diharapkan.

Bab V Penutup

Bab ini berisi kesimpulan dari Tugas Akhir serta saran sehubungan dengan adanya kemungkinan pengembangan sistem di masa yang akan datang.

STIKOM

8

LANDASAN TEORI

2.1. Bengkel

Pada kondisi tertentu, kendaraan bermotor memerlukan perawatan atau perbaikan. Perawatan dan perbaikan kendaraan harus dilakukan agar umur pakai kendaraan lebih panjang atau paling tidak sama dengan umur pakai yang telah diprediksikan dan dirancang oleh pabrik pembuat. Meskipun demikian, perawatan dan perbaikan kendaraan bukan merupakan pekerjaan yang mudah. Hal tersebut memerlukan pengetahuan khusus.

Untuk memperoleh pengetahuan tersebut, tentu saja dibutuhkan kemauan dan waktu. Namun sebagian besar pemilik kendaraan bermotor biasanya merasa dirinya tidak memiliki kedua hal tersebut. Berdasarkan hal tersebut,terbuka peluang bagi pihak lain yang memiliki kahlian dan peralatan kerja di bidang kendaraan bermotor (otomotif) untuk membuka usaha perbengkelan. Terjadilah transaksi antara orang yang membutuhkan perawatan atau perbaikan di bidang otomotif dan mereka yang memiliki keahlian serta peralatan di bidang tersebut. Hal ini dilakukan di bengkel otomotif.

Bengkel mobil diklasifikasikan berdasarkan dua kriteria, yaitu fasilitas pelayanan dan skala usaha yang dijalankan (Meliputi jumlah tenaga kerja, modal, dan kapasits kerja).

STIKOM

2.1.1. Fasilitas

Berdasarkan fasilitas pelayanan, bengkel mobil dapat dibedakan menjadi empat, yaitu:

A. Bengkel Dealer

Bengkel dealer merupakan bagian dari dealer otomotif yang memberikan pelayanan purnajual kepada konsumen. Bengkel jenis ini biasanya hanya melayani kendaraan dengan merek tertentu yang dijual di dealer tersebut. Pelayanan yang ditawarkan oleh bengkel dealer meliputi perawatan rutin hingga perbaikan yang memerlukan penggantian suku cadang. Bengkel jenis ini biasanya terdiri dari beberapa bagian khusus yang memberikan pelayanan perawatan atau perbaikan tertentu pada komponen mobil (mesin, balancing, body repair, dan sebagainya). Oleh karena itu, teknisi yang bekerja di bengkel ini juga memiliki spesialisasi tertentu dan dilengkapi peralatan yang mendukung pekerjaan.

B. Bengkel Pelayanan Umum

Bengkel pelayanan umum merupakan bengkel independen yang mampu melakukan perawatan dan perbaikan beberapa komponen mobil. Bengkel Semacam in dapat dipandang sebagai beberapa bengkel khusus yang menggabungkan diri menjadi sebuah bengkel yang lebih besar. Berbeda dengan bengkel dealer, bengkel ini bukan merupakan bagian dari

dealer otomotif. Oleh karena itu, pelayanan yang diberikan bengkel ini

tidak ditujukan untuk pelayanan purnajual sebuah produk otomotif. Selain

STIKOM

itu, bengkel pelayanan umum biasanya memberikan pelayanan perawatan dan perbaikan untuk berbagai merek kendaraan.

C. Bengkel Pelayanan Khusus

Bengkel pelayanan khusus adalah bengkel otomotif yang memiliki spesialisasi dalam hal perawatan dan perbaikan salah satu elemen mobil. Sebagai contoh bengkel reparasi bodi, radiator, AC, spooring dan

balancing, dan sebagainya. Spesialisasi yang dilakukan oleh bengkel

tersebut menuntut peralatan khusus sesuai dengan jenis operasi yang akan dilakukan. Bagian terpenting dari bengkel pelayanan khusus adalah spesialisasi keahlian tenaga kerja sesuai dengan kualifikasi pekerjaan yang akan dilakukan.

D. Bengkel Unit Keliling

Bengkel unit keliling memberikan pelayana berupa perbaikan yang dilakukan di lokasi mobil konsumen. Bengkel jenis ini terdiri dari beberapa buah mobil van dan derek yang secara periodik berpatroli di daerah tertentu, atau kadang-kadan menerima panggilan untuk memberi pelayanan kepada konsumen.

2.1.2. Skala Usaha

Berdasarkan skala usaha yang dijalankannya, bengkel mobil dapat diklasifikasikan menjadi dua, yaitu:

STIKOM

A. Bengkel Kecil

Bengkel kecil adalah bengkel yang meliputi bengkel skala garasi rumah dengan satu sampai lima orang pekerja, hingga bengkel permanen dengan tenaga kerja hingga 19 orang (definisi Biro Pusat Statistik tentang Usaha Kecil).

B. Bengkel Besar

Biro Pusat Statistik mengklasifikasikan usaha besar sebagai usaha yang mempekerjakan lebih dari 20 orang. Berdasarkan hal tersebut, sebuah bengkel dapat diklasifikasikan sebagai bengkel besar apabila memiliki pegawai lebih dari 20 orang. Bengkel besar dapat diklasifikasikan berdasarkan aset yang dimilikinya. Biasanya, orang-orang juga mengklasifikasikan bengkel besar apabila dilengkapi peralatan canggih sebagai peralatan kerjanya.

2.2. Sistem Pakar

Menurut Kusrini (2006) sistem pakar adalah sistem berbasis komputer yang menggunakan pengetahuan, fakta, dan teknik penalaran dalam memecahkan masalah yang biasanya hanya dapat dipecahkan oleh seorang pakar dalam bidang tertentu.

Pada dasarnya sistem pakar diterapkan untuk mendukung aktivitas pemecahan masalah. Beberapa aktivitas pemecahan yang dimaksud antara lain: pembuatan keputusan, pemandu pengetahuan, pembuatan desain, perencanaan, perkiraan, pengaturan, pengendalian, diagnosis, perumusan, penjelasan,

STIKOM

pemberian nasihat dan pelatihan. Sistem pakar juga dapat berfungsi sebagai asisten yang pandai dari seorang pakar.

Alasan mendasar mengapa sistem pakar dikembangkan untuk menggantikan seorang pakar adalah:

1. Dapat menyediakan kepakaran setiap waktu dan di berbagai lokasi.

2. Secara otomatis mengerjakan tugas-tugas rutin yang membutuhkan seorang pakar.

3. Seorang pakar akan pensiun atau pergi.

4. Menghadirkan/menggunakan jasa seorang pakar memerlukan biaya yang mahal.

5. Kepakaran dibutuhkan juga pada lingkungan yang tidak bersahabat. Ciri-ciri sistem pakar (Kusrini, 2006) adalah sebagai berikut:

1. Terbatas pada bidang yang spesifik.

2. Dapat memberikan penalaran untuk data-data yang tidak lengkap atau tidak pasti.

3. Dapat mengemukakan rangkaian alasan yang diberikannya dengan cara yang dapat dipahami.

4. Berdasarkan rule tertentu.

5. Dirancang untuk dapat dikembangkan secara bertahap. 6. Output bersifat anjuran.

7. Output tergantung dari dialog dengan user.

8. Knowledege base dan inference engine terpisah.

STIKOM

Keuntungan pemakaian sistem pakar (Kusrini, 2006) yaitu:

1. Membuat seseorang yang awam dapat bekerja seperti layaknya seorang pakar.

2. Dapat bekerja dengan informasi yang tidak lengkap atau tidak pasti 3. Meningkatkan output dan produktivitas.

4. Meningkatkan kualitas.

5. Sistem pakar menyediakan nasihat yang konsisten dan dapat mengurangi tingkat kesalahan.

6. Membuat peralatan yang kompleks lebih mudah dioperasikan karena sistem pakar dapat melatih pekerja yang tidak berpengalaman.

7. Andal (reliability).

8. Sistem pakar tidak dapat lelah atau bosan, konsisten dalam memberi jawaban dan selalu memberikan perhatian penuh.

9. Memiliki kemampuan dalam memecahkan suatu permasalahan yang kompleks.

10.Memungkinkan pemindahan pengetahuan ke lokasi yang jauh serta memperluas jangkauan pakar, dapat diperoleh dan dipakai di mana saja. Menurut Gonzales dan Dankel (1993), terdapat beberapa kelemahan sistem pakar, antara lain:

1.Jawaban yang diberikan tidak selalu benar, seperti halnya pakar yang tidak selalu benar.

2.Pengetahuan terbatas pada keahlian pakar.

STIKOM

User

(Case Facts Conclusions)

Inference Engine

Working Memory

(Case/Inferred facts Conclusion)

Knowledge Base

(Domain Knowledge)

3.Pengetahuan akan kebiasaan umum sulit direpresentasikan pada sistem, sehingga sistem kurang sadar akan hal lazim (kebiasaan yang sudah umum).

2.2.1 Komponen Sistem Pakar

Menurut Irawan (2007), sistem pakar terdiri atas tiga komponen utama, yaitu knowledge base, working memory dan inference engine. Struktur dasar sistem pakar dapat dilihat pada Gambar 2.1.

Gambar 2.1 Struktur dasar sistem pakar (Irawan, 2007: 7)

1. Knowledge Base

Knowledge base adalah bagian dari sebuah sistem pakar yang

mengandung/menyimpan pengetahuan. Pengetahuan ini merupakan representasi pengetahuan dari seorang pakar. Knowledge base yang dikandung oleh sebuah sistem pakar berbeda, tergantung pada bidang kepakaran dari sistem yang dibangun. Knowledge base direpresentasikan dalam berbagai macam bentuk, salah satunya adalah dalam bentuk sistem berbasis aturan (ruled-based system).

STIKOM

2. Working Memory

Working memory mengandung/menyimpan fakta-fakta (baik yang

dimasukkan oleh pengguna maupun fakta baru) yang ditemukan selama proses konsultasi dengan sistem pakar. Selama proses konsultasi pengguna umum memasukkan fakta-fakta yang dibutuhkan, kemudian sistem akan mencari padanan fakta tersebut dengan informasi yang ada dalam knowledge base untuk menghasilkan fakta baru. Fakta baru yang merupakan hasil kesimpulan dari sistem akan dimasukkan ke dalam working memory.

3. Inference Engine

Inference engine adalah bagian dari sistem pakar yang bertugas mencari

padanan antara fakta yang ada di dalam working memory dengan fakta-fakta tentang pengetahuan tertentu dari pakar yang ada di dalam knowledge base. Selanjutnya inference engine akan menarik kesimpulan dari masalah yang diajukan kepada sistem. Terdapat dua metode yang dapat digunakan untuk mencari kesimpulan, yaitu forward chaining dan backward chaining.

4. User (Kusrini, 2006)

User adalah seseorang yang berkonsultasi dengan sistem untuk

mendapatkan saran / kesimpulan yang disediakan oleh pakar. 2.2.2 Forward Chaining

Metode forward chaining (data driven) adalah suatu metode yang menghasilkan kesimpulan dari seperangkat data yang diketahui (Irawan, 2007). Menurut Kusrini (2006), runut maju (forward chaining) berarti menggunakan himpunan aturan kondisi-aksi. Dalam metode forward chaining, data digunakan

STIKOM

untuk menentukan aturan mana yang akan dijalankan, kemudian aturan tersebut dijalankan. Mungkin proses menambahkan data ke memori kerja. Proses diulang sampai menemukan suatu hasil. Cara kerja metode forward chaining dapat dilihat pada Gambar 2.2.

Gambar 2.2 Forward Chaining (Kusrini, 2006:36)

2.2.3 Backward Chaining

Metode backward chaining (goal driven) adalah suatu metode yang berawal dari proses memilih beberapa kesimpulan yang mungkin dan mencoba membuktikan kesimpulan tersebut dari bukti-bukti yang ada (Irawan, 2007). Menurut Kusrini (2006), runut balik (backward chaining) merupakan metode penalaran kebalikan dari runut maju. Dalam metode backward chaining, penalaran dimulai dengan tujuan yang merunut balik ke jalur yang akan mengarahkan ke tujuan tersebut. Cara kerja metode backward chaining dapat dilihat pada Gambar 2.3.

Gambar 2.3 Backward Chaining (Kusrini, 2006:37)

STIKOM

2.2.4 Verifikasi

Verifikasi adalah suatu proses yang bertujuan untuk memastikan bahwa sistem telah berlaku dalam kondisi yang ditetapkan. Verifikasi terdiri dari dua proses. Proses pertama adalah memeriksa pelaksanaan suatu sistem secara spesifik. Proses kedua adalah memeriksa konsistensi dan kelengkapan dari basis pengetahuan (knowledge base). Verifikasi dijalankan ketika ada penambahan atau perubahan pada rule, karena rule sudah terdapat pada sistem. Tujuan verifikasi adalah untuk memastikan adanya kecocokkan antara sistem dengan apa yang sistem kerjakan dan juga untuk memastikan bahwa sistem terbebas dari kesalahan. Berikut ini adalah beberapa metode pemeriksaan aturan-aturan dalam suatu basis pengetahuan (Gonzales dan Dankel, 1993).

1. Redundant rules

Dikatakan redundant rules jika dua rule atau lebih mempunyai premise dan

conclusion yang sama.

Contoh :

Rule 1: If the humidity is high and the temperature is hot

Then there will be thunderstorms

Rule 2: If the temperature is hot and the humidity is high

Then there will be thunderstorms

2. Conflicting rules

Conflicting rules terjadi ketika dua rule atau lebih mempunyai premise yang sama

tetapi conclusion yang berbeda.

STIKOM

Contoh :

Rule 1: If the temperature is hot and the humidity is high

Then there will be sunshine

Rule 2: If the temperature is hot and the humidity is high

Then there will be no sunshine

3. Subsumed rules

Suatu keadaan dapat dikatakan subsumed rules jika rule mempunyai constraint yang lebih atau kurang tetapi mempunyai conclusion yang sama.

Contoh :

Rule 1: If the temperature is hot and the humidity is high

Then there will be thunderstorms

Rule 2: If the temperature is hot

Then there will be thunderstorms

4. Circular rules

Circular rules merupakan proses perulangan dari suatu rule karena premise dari

salah satu rule merupakan conclusion dari rule yang lain, atau kebalikannya. Contoh :

Rule 1: If X and Y are brothers

Then X and Y have the same parents

Rule 2: If X and Y have the same parents

Then X and Y are brothers

STIKOM

5. Unnecessary IF condition

Unnecessary IF terjadi ketika dua rule atau lebih mempunyai conclusion yang

sama tetapi salah satu dari rule tersebut mempunyai premise yang tidak perlu dikondisikan dalam rule karena tidak mempunyai pengaruh apapun.

Contoh :

Rule 1: If the patient has the pink spots and the patient has a fever

Then the patient has measles

Rule 2: If the patient has the pink spots and the patient does not have fever

Then the patient has measles

6. Dead-end rules

Dead-end rules adalah tindakan yang tidak mempengaruhi conclusion dan tidak

digunakan oleh rule yang lain untuk menghasilkan suatu conclusion. Contoh :

Rule 1: If the gauge reads empty

Then the gas tank is empty

7. Missing Rules

Missing rules merupakan suatu aturan yang ditandai dengan fakta yang tidak

pernah digunakan dalam inference process. 8. Unreachable Rules

Unreachable rules merupakan suatu aturan yang premisenya tidak akan pernah

cocok dengan keadaan sistem, baik karena missing rule atau kurangnya data masukan.

STIKOM

2.2.5 Dependency Diagram

Setelah diketahui urutan kerja sistem dalam mencari keputusan dari diagram blok, langkah selanjutnya adalah membuat dependency diagram (diagram ketergantungan). Menurut Dologite (1993) dependency diagram adalah suatu relasi yang menunjukkan hubungan atau ketergantungan antara inputan jawaban, aturan-aturan (rule), nilai-nilai dan direkomendasikan ke dalam sistem berbasis pengetahuan. Contoh dependency diagram dapat dilihat pada Gambar 2.5

Set 2 R ul e 6-8 Set 3 R ule 9-11 S et 1 R ul e 1-5 Member Status Problem Recommended Support ? member (yes,no) ? ID_Valid (yes,no) ? reason

(new_case, follow_up_case, information_other) ? temperature

(normal, Abnormal, not_known) ? Other_symptoms (yes, no) Level_1 Level_2 Level_3 Information_other Non_member

Gambar 2.4 Dependency Diagram (Dologite, 1993:23) 2.2.6 Decision Table

Setelah diagram ketergantungan dibuat, langkah berikutnya adalah membuat

Decision table. Menurut Dologite (1993), decision table diperlukan untuk

menunjukan hubungan timbal balik antara nilai-nilai pada hasil fase antara atau rekomendasi akhir sistem. Sebelum membuat decision table, diperlukan informasi mengenai jumlah rule yang akan dibuat. Jumlah rule dapat diketahui dari jumlah

STIKOM

parameter dan kemungkinan jawaban yang ada, seperti pada Gambar 2.6. Sebagai contoh dari pembuatan decision table dapat dilihat pada Tabel 2.1.

Gambar 2.5 Penentuan Jumlah Rule (Dologite, 1993:24) Tabel 2.1 Decision Table (Dologite, 1993:24) Rule Member

Status

Reason Problem Concluding

Recommendation for support level

A1 Ok New_case Serious Level_1

A2 Ok New_case Non_serious Level_2

A3 Ok Follow_up_case Serious Level_1

A4 Ok Follow_up_case Non_serious Level_3

A5 Ok Information_other Serious Information_other A6 Ok Information_other Non_serious Information_other

A7 Not_ok New_case Serious Non_member

A8 Not_ok New_case Non_serious Non_member

A9 Not_ok Follow_up_case Serious Non_member

A10 Not_ok Follow_up_case Non_serious Non_member A11 Not_ok Information_other Serious Non_member A12 Not_ok Information_oher Non_serious Non_member

2.2.7 Reduced Decision Table

Reduced decision table adalah pembuatan tabel yang nilai-nilainya

didapat dari mereduksi decision table. Setelah didapatkan nilai dari decision table,

Condition : Member_Status (ok, not_ok) =2

Reason (new_case, follow_up_case, information_other) =3

Problem (serious, non_serious) =2

STIKOM

akan direduksi untuk mendapatkan nilai dari kondisi terakhir. Sebagai contoh dari

reduced decision table dapat dilihat pada Tabel 2.2

Tabel 2.2 Reduced Decision Table (Dologite, 1993:24) Rule Member

Status

Reason Problem Concluding

Recommendation for support level

B1 Ok New_case Serious Level_1

B2 Ok New_case Non_serious Level_2

B3 Ok Follow_up_case Serious Level_1

B4 Ok Follow_up_case Non_serious Level_3

B5 Ok Information_other - Information_other

B6 Not_ok - - Non_member

2.3. Rekayasa Perangkat Lunak

Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. (Sommerville, 2003). Pada definisi ini, ada dua istilah kunci yaitu:

1. Disiplin rekayasa, perekayasa membuat suatu alat bekerja. Menerapkan teori, metode, dan alat bantu yag sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan, walaupun tidak ada teori atau metode yang mendukung. Perekayasa juga menyadari bahwa mereka harus bekerja dalam batasan organisasi dan keuangan, sehingga mereka berusaha mencari solusi dalam batasan-batasan ini.

STIKOM

2. Semua aspek produksi perangkat lunak, rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti manajemen proyek perangkat lunak dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi perangkat lunak.

Secara umum, rekayasa perangkat lunak memakai pendekatan sistematis dan terorganisasi terhadap pekerjaan mereka karena cara ini seringkali paling efektif untuk menghasilkan perangkat lunak berkualitas tinggi. Namun demikian, rekayasa ini sebenarnya mencakup masalah pemilihan metode yang paling sesuai untuk satu set keadaan dan pendekatan yang lebih kreatif, informal terhadap pengembangan yang mungkin efektif pada beberapa keadaan. Pengembangan informal sangat cocok untuk pengembangan sistem e-commerce web membutuhkan gabungan keahlian perangkat lunak dan perancangan grafis.

2.3.1. Proses Perangkat Lunak

Proses perangkat lunak adalah serangkaian kegiatan-kegiatan dan hasil-hasil relevannya yang menghasil-hasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan perekayasa perangkat lunak. Ada empat kegiatan proses dasar yang umum bagi seluruh kegiatan proses perangkat lunak. Kegiatan-kegiatan ini adalah :

1. Spesifikasi perangkat lunak, fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan

STIKOM

2. Pengembangan perangkat lunak, perangkat lunak yang memenuhi spesifikasi tersebut harus diproduksi.

3. Validasi perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.

4. Evolusi perangkat lunak, perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan yang berubah-ubah.

Proses perangkat lunak yang berbeda mengatur kegiatan ini dengan cara berbeda dan dijelaskan dengan tingkat kerincian yang berbeda pula. Waktu kegiatan bervarias, sebagaimana hasilnya. Pegaturan yang berbeda dapat menggunakan proses yang berbeda untuk menghasilkan produk dengan jenis yang sama. Namun demikian, untuk beberapa jenis aplikasi tertentu, beberapa proses lebih sesuai dari yang lainnya jika digunakan proses yang tidak sesuai, maka kualitas penggunaan produk perangkat lunak yang akan dikembangkan tersebut mungkin berkurang.

2.3.2. Model Proses Perangkat Lunak

Model proses pengembangan perangkat lunak adalah sebagai berikut :

1. Model air terjun (waterfall). Model ini mengambil kegiatan proses dasar seperti spesifikasi, pengembangan, validasi dan evolusi, dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti

STIKOM

spesifikasi persyaratan, perancangan perangkat lunak, implemetasi, pengujian dan seterusnya.

2. Pengembangan evolusioner. Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Suatu sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian diperbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan bagi kebutuhan pelanggan.

3. Pengembangan sistem formal. Pendekatan ini didasarkan atas pembuatan spesifik sistem matematis dan pentransformasian spesifikasi, dengan memakai metode matematis untuk membangun program. Verifikasi komponen sistem dilakukan dengan membuat argumen matematis yang disesuaikan dengan spesifikasi.

Pengembangan berdasarkan pemakaian ulang. Pendekatan ini didasarkan atas adanya komponen yang dapat dipakai untuk jumlah yang signifikan . Proses pengembangan sistem terfokus pada integrasi komponen-komponen ini ke dalam suatu sistem dan bukan mengembangkan dari awal.

2.4. Sistem Basis Data

Sistem basis data merupakan sistem yang terdiri atas kumpulan file (tabel) yang saling berhubungan (dalam sebuah basis data di sebuah komputer) dan sekumpulan program (DBMS) yang memungkinkan beberapa pemakai dan atau

STIKOM

program lain untuk mengakses dan memanipulasi file-file (tabel-tabel) tersebut (Fathansyah, 2007:9)

2.4.1. Komponen Basis Data

Menurut Kusrini (2007 : 11), komponen-komponen sistem basis data meliputi :

1. Perangkat Keras (Hardware) sebagai pendukung operasi pengolahan data. Perangkat keras computer adalah semua bagian fisik computer. Contoh dari perangkat keras computer yaitu : mouse, keyboard, monitor, CPU, memori, dan lain-lain

2. Sistem Operasi (Operating System) atau perangkat lunak untuk mengolah basis data.

Sistem operasi merupakan suatu software sistem yang bertugas untuk melakukan control dan managemen hardware serta operasi-operasi dasar sistem, termasuk menjalankan software aplikasi seperti program-program pengolahan kata dan browser web. Secara umum sistem operasi adalah software pada lapisan pertama yang ditaruh pada memori computer pada saat computer dinyalakan.

3. Basis Data (Database) sebagai inti dari sistem basis data.

4. Database Management System (DBMS)

DBMS adalah software yang menangani semua akses ke basis data. Secara konsep yang terjadi dalam DBMS adalah sebagai berikut :

STIKOM

a. User melakukan pengaksesan basis data untuk informasi yang diperlukannya menggunakan bahasa manipulasi data, biasanya disebut SQL

b. DBMS menerima request dari user dan menganalisanya.

c. DBMS memeriksa skema eksternal user, pemetaan eksternal/konseptual, skema konseptual, pemetaan konseptual/internal, dan struktur penyimpanan.

d. DBMS mengeksekusi operasi-operasi yang diperlukan untuk memenuhi permintaan user.

5. Pemakai (User)

Pemakai merupakan orang atau sistem yang akan mengakses dan merubah isi basis data. Beberapa jenis pemakai basis data yaitu :

a. Programmer Aplikasi : orang yang mengkodekan aplikasi dengan bahasa pemrograman.

b. User Mahir : orang yang mampu menggunakan basis data secara langsung dengan menggunakan DBMS.

c. User Umum/End User : orang yang akan memakai basis data dengan perantara program aplikasi.

d. User khusus : biasa berupa sistem lain. 6. Aplikasi Lain

Aplikasi lain merupakan software yang dibuat untuk memberikan

interface kepada user sehingga lebih mudah dan terkontrol dalam

mengakses basis data.

STIKOM

2.5. Web Developer

Menurut Kadir (2005:2), World Wide Web (WWW) atau biasa disebut dengan web merupakan salah satu sumber daya Internet yang berkembang pesat. Pertama kali aplikasi web dibangun hanya dengan menggunakan bahasa yang disebut HTML (HyperText Markup Language) dan protokol yang digunakan dinamakan HTTP (HyperText Transfer Protocol). Pada perkembangan berikutnya, sejumlah skrip dan objek dikembangkan untuk memperluas kemampuan HTML yang sekarang ini terdapat banyak skrip seperti: PHP dan ASP, sedangkan contoh yang berupa objek antara lain adalah applet (java) (Kadir, 2005:2). Jadi aplikasi web atau aplikasi berbasis web (Web-based application) adalah aplikasi untuk menyampaikan informasi kepada pengguna yang menggunakan layanan Internet berbasis web.

Dalam aplikasi tersebut, terjadi pertukaran antara klien (komputer yang meminta informasi) dengan server (komputer yang memasok atau menanggapi informasi). Web memberikan informasi secara online melalui internet langsung. Klien melakukan permintaan informasi dengan menggunakan browser (contoh

browser: Internet Explorer, Opera, Mozilla, dan sebagainya). Server menerima

informasi dan melayani permintaan dari client. Hal ini biasa disebut dengan web server (contoh web server: Apache, IIS, Xitami, dan sebagainya). Setelah itu, web server akan berkomunikasi dengan middleware (contoh middleware: ASP, JSP, PHP, dan sebagainya) untuk bisa berhubungan dengan basis data atau database (contoh database: access, oracle, sql, dan sebagainya). Setelah berinteraksi

STIKOM

dengan database, server yang telah mendapatkan informasi akan memberikan tanggapan terhadap klien yang meminta informasi tadi.

2.5.1. Unsur - Unsur Dalam Penyediaan Website atau Situs

Untuk menyediakan sebuah website, maka harus tersedia unsure-unsur penunjang, unsure-unsur penunjang dari website antara lain adalah :

1. Nama Domain

Nama domain atau biasa disebut dengan Domain Name atau URL adalah alamat unik di dunia internet yang digunakan untuk mengidentifikasi sebuah website, atau dengan kata lain domain name adalah alamat yang digunakan untuk menemukan sebuah website pada dunia internet, Nama domain diperjual belikan secara bebas di internet dengan status sewa tahunan. Setelah Nama Domain itu terbeli di salah satu penyedia jasa pendaftaran, maka pengguna disediakan sebuah kontrol panel untuk administrasinya. Jika pengguna lupa/tidak memperpanjang masa sewanya, maka nama domain itu akan di lepas lagi ketersediaannya untuk umum. Nama domain sendiri mempunyai identifikasi ekstensi/akhiran sesuai dengan kepentingan dan lokasi keberadaan website tersebut. Contoh nama domain ber-ekstensi internasional adalah com, net, org, info, biz, name, ws. Contoh nama domain ber-ekstensi lokasi Negara Indonesia adalah :

- .co.id : Untuk Badan Usaha yang mempunyai badan hukum sah

- .ac.id : Untuk Lembaga Pendidikan

- .go.id : Khusus untuk Lembaga Pemerintahan Republik Indonesia

STIKOM

- .mil.id : Khusus untuk Lembaga Militer Republik Indonesia

- or.id : Untuk segala macam organisasi yand tidak termasuk dalam kategori ac.id, co.id, go.id, mil.id dan lain lain

- sch.id : Untuk Lembaga Pendidikan yang menyelenggarakan pendidikan seperti SD, SMP dan atau SMU

- web.id : Ditujukan bagi badan usaha, organisasi ataupun perseorangan yang melakukan kegiatannya di World Wide Web.

2. Rumah tempat website (Web hosting)

Web Hosting dapat diartikan sebagai ruangan yang terdapat dalam harddisk tempat menyimpan berbagai data, file-file, gambar, video, data email, statistik, database dan lain sebagainya yang akan ditampilkan di website. Besarnya data yang bisa dimasukkan tergantung dari besarnya web hosting yang disewa/dipunyai, semakin besar web hosting semakin besar pula data yang dapat dimasukkan dan ditampilkan dalam website.

Web Hosting juga diperoleh dengan menyewa. Pengguna akan memperoleh kontrol panel yang terproteksi dengan username dan password untuk administrasi websitenya. Besarnya hosting ditentukan ruangan harddisk dengan ukuran MB (Mega Byte) atau GB (Giga Byte). Lama penyewaan web hosting rata-rata dihitung per tahun. Penyewaan hosting dilakukan dari perusahaan-perusahaan penyewa web hosting yang banyak dijumpai baik di Indonesia maupun Luar Negeri. Lokasi peletakan pusat data (datacenter) web hosting

STIKOM

bermacam-macam. Ada yang di Jakarta, Singapore, Inggris, Amerika, dll dengan harga sewa bervariasi.

3. Bahasa Program (Scripts Program).

Bahasa Program Adalah bahasa yang digunakan untuk menerjemahkan setiap perintah dalam website yang pada saat diakses. Jenis bahasa program sangat menentukan statis, dinamis atau interaktifnya sebuah website. Semakin banyak ragam bahasa program yang digunakan maka akan terlihat website semakin dinamis, dan interaktif serta terlihat bagus.

Beragam bahasa program saat ini telah hadir untuk mendukung kualitas website. Jenis jenis bahasa program yang banyak dipakai para desainer website antara lain HTML, ASP, PHP, JSP, Java Scripts, Java applets, XML, Ajax dsb. Bahasa dasar yang dipakai setiap situs adalah HTML sedangkan PHP, ASP, JSP dan lainnya merupakan bahasa pendukung yang bertindak sebagai pengatur dinamis, dan interaktifnya situs. Bahasa program ASP, PHP, JSP atau lainnya bisa dibuat sendiri. Bahasa program ini biasanya digunakan untuk membangun portal berita, artikel, forum diskusi, buku tamu, anggota organisasi, email, mailing list dan lain sebagainya yang memerlukan update setiap saat.

2.5.2. Intranet

Intranet (Internal Network) mulai didengung-dengungkan pada pertengahan tahun 1995 oleh beberapa penjual produk jaringan yang mengacu pada kebutuhan informasi dalam bentuk Web di dalam perusahaan. Intranet merupakan jaringan komputer dalam perusahaan yang menggunakan komunikasi

STIKOM

data standar seperti dalam Internet. Artinya, semua fasilitas Internet dapat digunakan untuk kebutuhan dalam perusahaan (atau dalam suatu organisasi). Dengan kata lain, Intranet dapat dikatakan ber-internet dalam lingkungan yang terbatas.

Adapun fasilitas standar Internet yang digunakan dalam Intranet adalah standar protokol TCP/IP. Standar tersebut memungkinkan protokol jaringan melakukan komunikasi, menerima dan mengirimkan data ke terminal yang lain. Standar yang lain adalah FTP (File Transfer Protocol) yang merupakan pelayanan resource sharing, sebuah fasilitas untuk mengambil file yang ada di Internet. SMTP (Simple Mail Transfer Protocol) yang merupakan dasar dari

e-mail untuk berkomunikasi serta MIME (Multipurpose Internet Mail Extensions)

yang merupakan standar untuk mendefinisikan format biner, grafik dan suara agar dapat ditransmisikan dengan e-mail. Selain itu terdapat protokol NNTP (Network

News Transfer Protocol) dan POP (Post Office Protocol).

Protokol lainnya yang relatif baru dan sangat penting bagi Internet maupun Intranet adalah HTTP (HyperText Transport Protocol). Komputer yang memakai HTTP (dengan menggunakan perangkat lunak tertentu) disebut Web server. HTTP bertanggung jawab atas distribusi dan kolaborasi dokumen yang ada di Web server. HTTP tidak perlu tahu data yang dibawanya dan bahkan sistem operasi yang menjalankan Web server. Bila suatu platform mendukung TCP/IP danmultitasking, maka HTTP dapat digunakan. Kini, HTTP merupakan dasar dari layanan World Wide Web (WWW) Inter/Intranet.

STIKOM

Gambar 2.6 Aliran hardware dan logik dalam Intranet

Secara umum, seperti yang telah disebutkan sebelumnya bahwa teknologi yang digunakan antara Internet dan Intranet adalah sama. Namun demikian terdapat perbedaan antara Internet dengan Intranet dilihat dari perspektif jangkauan dan penggunaannya, yakni:

 Lingkup akses dan jangkauan.

 Cara teknologi yang digunakan untuk berkomunikasi.

 Tujuan dari terselenggaranya komunikasi.

Pada Internet, lingkupnya adalah global, komunikasi lewat saluran telekomunikasi publik, dan penggunanya bisa siapa saja tanpa membedakan posisi seseorang dalam kaitannya dengan isi informasi. Pada Intranet, cakupannya lebih terbatas, yakni di dalam organisasi; hubungannya antar kelompok kerja atau departemen di dalam perusahaan; penggunaannya oleh komunitas yang sudah ditentukan.

STIKOM

5.1.Testing dan Implementasi

Menurut standart ANSI/IEEE 1059, Testing adalah proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan (defects/error/bugs) dan mengevaluasi fitur-fitur dari entitas software.

Menurut Romeo (2003:3), Testing software adalah proses mengopersikan

software dalam suatu kondisi yang dikendalikan untuk:

1. Verifikasi

Apakah telah berlaku sebagaimana yang di tetapkan (menurut spesifikasi)? 2. Mendeteksi Error

3. Validasi

Apakah spesifikasi yang di tetapkan telah memenuhi keinginan atau kebutuhan pengguna yang sebenarnya ?

Menurut Romeo (2003:33), Test Case merupakan tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan kondisi ataupun hasil yang telah ditentukan sebelumnya. Metode testing ini dibagi menjadi dua, yaitu:

1. White Box Testing

White Box Testing atau glass box testing atau clear box testing adalah

suatu metode test case yang menggunakan struktur kendali dari desain prosedural. Metode desain test case ini dapat menjamin :

a. Semua jalur (path) yang independen/terpisah dapat dites setidaknya sekali tes. b. Semua logika keputusan dapat ditesdengan jalur yang salah atau jalur yang benar.

STIKOM

c. Semua loop dapat dites terhadap batasannya dan ikatan operasional. d. Semua struktur internal data dapat dites untuk memastikan validasinya.

2. Black box testing

Black box testing atau behavioral testing atau specification-based testing,

input/output testing atau functional testing dilakukan tanpa sepengetahuan detil

struktur internal dari sistem atau komponen yang dites. Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan spesifikasi kebutuhan dari

software.

Menggunakan black box testing, perekayasa software dapat menggunakan sekumpulan kondisi masukan yang dapat secara penuh memeriksa keseluruhan kebutuhan fungsional pada suatu program. Kategori error dapat diketahui melalui black box testing, antara lain :

a. Fungsi yang hilang atau tidak benar. b. Error dari antar muka.

c. Error dari struktur data atau akses eksternal database. d. Error dari kinerja atau tingkah laku.

e. Error dari inialisasi dan terminasi.

STIKOM

36

ANALISIS DAN PERANCANGAN SISTEM

3.1 Analisis Sistem

Supaya bengkel masih dapat berjalan dengan baik meski Service Advisor (SA) berhalangan hadir, bengkel harus mempunyai aplikasi yang dapat menggantikan SA dalam hal penentuan tindakan / pekerjaan, pemberian estimasi suku cadang yang perlu diganti, estimasi waktu dan biaya yang disimpulkan berdasarkan keluhan pelanggan.

Dalam menentukan tindakan / pekerjaan yang harus dilakukan, aplikasi ini akan menggunakan sistem pakar dengan metode pencarian forward chaining. Setelah pekerjaan ditentukan, aplikasi akan secara otomatis memberikan estimasi suku cadang yang dibutuhkan berdasarkan pekerjaan yang telah ditentukan sebelumnya. Dari semua pekerjaan yang telah ditentukan, juga akan dapat digunakan untuk menghitung estimasi lama pekerjaan. Yang terakhir, dari pekerjaan dan suku cadang yang dibutuhkan akan menghasilkan estimasi jumlah biaya yang harus dibayar oleh pelanggan.

Aplikasi yang akan dibuat tidak hanya bisa memberikan estimasi, tetapi harus bisa mengolah hasil dari estimasi tersebut. Estimasi tersebut akan langsung disimpan ke dalam detail dari mobil yang akan diservis, sehingga aplikasi akan mempunyai fungsi untuk mengetahui daftar mobil yang sedang atau akan diservis beserta detilnya. Dalam detail mobil yang sedang diservis terdapat juga fungsi untuk menambah atau menghapus pekerjaan dan suku cadang.

STIKOM

Untuk menjalankan transaksi dalam aplikasi ini maka harus ada fungsi untuk mengatur tabel-tabel master yaitu tabel pekerjaan yang meliputi daftar pekerjaan dan harga pekerjaan, tabel suku cadang yang meliputi daftar suku cadang dan harga suku cadang, tabel pegawai, serta tabel mobil dan pelanggan.

Selanjutnya untuk mempermudah SA dalam hal pencatatan keluhan saat SA harus mengecek kondisi mobil, SA akan diberikan sebuah tablet PC sehingga SA tidak perlu bolak-balik ke ruangan untuk menginputkan data karena SA dapat mengakses aplikasi dari tablet PC tersebut. Tablet PC ini akan terhubung dengan jaringan intranet server melalui koneksi WiFi.

3.2 Perancangan Sistem

Perancangan sistem dibuat dalam bentuk diagram blok, dependency

diagram, arsitektur sistem, data flow diagram, entity relationship diagram yang

berupa conseptual data model dan physical data model, struktur tabel,

perancangan input / output dan rancangan uji coba aplikasi.

STIKOM

text

text

text

text text

Keluhan Pelanggan

Proses Diagnosa Penentuan Pekerjaan Rule Sistem Pakar

Data Suku Cadang

Data Pekerjaan _{Proses Generate}

Laporan

Laporan Transaksi

Laporsn Beban Mekanik Laporan Loyalitas Pelanggan

Laporan Suku Cadang

text

Estimasi Waktu Estimasi Biaya

Estimasi Suku Cadang Estimasi Pekerjaan

Detail Harga Data Mekanik

3.2.1 Diagram Blok Aplikasi Service Advisor

Gambar 3.1 Diagram Blok Aplikasi Service Advisor pada bengkel mobil

Diagram blok seperti gambar 3.1 di atas menggambarkan input, proses dan output sebagai berikut :

A. Input

1. Rule Sistem Pakar

Rule sistem pakar didapatkan dari seorang pakar atau orang yang ahli. Dalam tugas akhir ini rule sistem pakar diperoleh dari SA pada Karunia Motor dan beberapa mekanik melalui wawancara. Penentuan rule sistem pakar sendiri mempunyai langkah-langkah yang harus dilakukan. Pertama-tama adalah menentukan parameter dan nilai yang dapat dilihat dari contoh rule set dalam

dependency diagram pada gambar 3.1 berikut.

STIKOM

? Indikator Lampu Aki Menyala (Ya / Tidak)

? Bunyi Klakson Diagnosa

Penyalaan (Kuat / Lemah)

- Aki Rusak

- Alternator Bermasalah - Starter Kuat

? Kondisi Starter (Dapat respon / Tidak dapat respon)

Gambar 3.2 Rule Set Dalam Dependency Diagram

Satu kelompok aturan, yang terdiri dari beberapa pertanyaan dan memiliki kesimpulan disebut rule set. Rule set yang sudah ada masih bisa dikombinasikan dengan pertanyaan atau rule set lainnya, sehingga dapat membentuk rule set baru.

Indikator lampu aki menyala, bunyi klakson, kondisi starter dan diagnosa penyalaan adalah parameter-parameter yang meyusun rule set sistem pakar. Diagnosa penyalaan merupakan parameter parent dari parameter Indikator lampu aki menyala, bunyi klakson dan kondisi starter yang juga bisa dibilang parameter

child. Parameter child merupakan aturan, sedangkan parameter parent merupakan

kesimpulan.

Setiap parameter mempunyai nilai. Dalam rule set ini parameter indikator lampu menyala mempunyai nilai ya dan tidak, parameter bunyi klakson mempunyai nilai kuat dan lemah, parameter kondisi starter mempunyai nilai mendapat respon dan tidak mendapat respon, dan yang parameter diagnosa penyalaan mempunyai nilai aki rusak, alternator bermasalah dan starter kuat.

Langkah selanjutnya adalah menentukan aturan-aturan dari rule set yang ada melalui tabel keputusan yang dapat dilihat pada tabel 3.1 berikut.

STIKOM

Tabel 3.1 Rule Set Dalam Decision Table

Rule Lampu Aki

Menyala Bunyi Klakson Kondisi Starter Diagnosa Penyalaan

1 Ya Lemah

Starter tidak mendapat respon

Alternator Bermasalah

2 Ya Lemah

Starter mendapat respon

Aki Rusak

3 Ya Kuat

Starter tidak mendapat respon

Alternator Bermasalah

4 Ya Kuat

Starter mendapat respon

Aki Rusak

5 Tidak Lemah

Starter tidak mendapat respon

Alternator Bermasalah

6 Tidak Lemah

Starter mendapat respon

Aki Rusak

7 Tidak Kuat

Starter tidak mendapat respon

Alternator Bermasalah

8 Tidak Kuat

Starter mendapat respon

Starter Kuat

Aturan-aturan ini yang akan dijadikan standar saat melakukan diagnosa. Sebagai contoh, dalam decision table diatas pada rule 1 dapat dibaca seperti ini :

if Lampu Aki Menyala = Ya

and Bunyi Klakson = Lemah

and Kondisi Starter = Tidak Mendapat Respon

then Diagnosa Penyalaan = Alternator Bermasalah

STIKOM

2. Keluhan Pelanggan

Keluhan pelanggan pada proses diagnosa penentuan pekerjaan merupakan keluhan yang didapatkan dari pelanggan ataupun pengecekan terhadap mobil pelanggan. Aplikasi akan memberikan daftar seluruh kemungkinan keluhan berdasarkan parameter child sistem pakar, sehingga SA hanya perlu memilih keluhan yang cocok dengan keluhan yang diberikan pelanggan.

3. Estimasi Pekerjaan

Estimasi pekerjaan pada proses generate laporan merupakan data estimasi pekerjaan yang diberikan oleh SA. Data estimasi ini didapatkan dari pencocokan keluhan pelanggan dengan rule sistem pakar.

4. Estimasi Suku Cadang

Estimasi suku cadang pada proses generate laporan merupakan data estimasi suku cadang yang diperlukan berdasarkan pekerjaan apa yang diberikan. 5. Data Mekanik

Data mekanik pada proses generate laporan merupakan data mekanik yang mempunyai tanggung jawab terhadap mobil yang akan diservice.

6. Data Pekerjaan

Data pekerjaan pada proses generate laporan merupakan data pekerjaan lain yang ditambahkan jika ternyata ada kerusakan lain pada mobil.

7. Data Suku Cadang

Data suku cadang pada proses generate laporan merupakan data suku cadang lain yang ditambahkan jika ternyata ada penambahan data pekerjaan.

STIKOM

8. Detail Harga

Detail harga pada proses generate laporan merupakan detail harga masing-masing pekerjaan dan suku cadang yang perlu ditambahkan.

B. Proses

1. Proses diagnosa penentuan pekerjaan

Proses diagnosa penentuan pekerjaan adalah proses awal dalam menentukan estimasi yang dibutuhkan dalam sistem. Pertama-tama pelanggan yang datang memberikan informasi mengenai mobil dan pelanggan tersebut. Setelah itu SA akan mendengarkan keluhan pelanggan agar SA dapat menjawab pertanyaan-pertanyaan dari aplikasi yang dijalankan pada tablet PC.

Pertanyaan yang muncul dari aplikasi merupakan kemungkinan keluhan-keluhan yang biasanya ada. Jadi SA tinggal memilih keluhan-keluhan yang sama dengan yang dikeluhkan pelanggan ataupun dari hasil mengecek langsung mobil pelanggan. Hasil dari jawaban-jawaban yang dimasukkan tersebut akan diolah dengan cara mencocokkan data jawaban dengan aturan-aturan yang ada pada rule sistem pakar agar bisa menghasilkan estimasi pekerjaan yang harus dilakukan. Selanjutnya dari estimasi pekerjaan tersebut akan menghasilkan estimasi suku cadang yang harus diganti, lama waktu pengerjaan serta total biaya keseluruhan.

Setelah mendapat persetujuan dari pelanggan mengenai estimasi-estimasi tersebut, estimasi yang keluar akan diteruskan kepada 3 bagian lainnya yaitu bengkel, gudang dan kasir. Estimasi pekerjaan akan masuk dalam bagian bengkel. Estimasi mengenai suku cadang yang dibutuhkan akan masuk ke dalam gudang sehingga petugas di gudang dapat segera menyiapkan dan mengantarkan ke

STIKOM

bagian bengkel. Terakhir adalah bagian kasir, semua data estimasi akan masuk dalam bagian kasir untuk keperluan pencatatan nota yang berisi detil dari mobil yang diservis.

2. Proses Generate Laporan

Proses Generate Laporan adalah proses pengumpulan dan pengolahan data-data supaya dapat menghasilkan laporan-laporan yang dibutuhkan. Pada bagian bengkel, aplikasi akan dengan sendirinya mengatur mekanik yang akan mengerjakan mobil tersebut. Penentuan mekanik ini dilihat dari mekanik yang sedang tidak bekerja. Jika semua mekanik sedang bekerja, maka akan dilihat dari penjadwalan pengerjaan dari masing-masing mekanik karena setiap pengerjaan ada estimasi waktunya, jadi dapat dilihat mekanik mana yang akan selesai terlebih dahulu. Pencatatan ini dimaksudkan agar pihak bengkel dapat mengetahui total beban kerja dari masing-masing mekanik.

Ada kemungkinan saat servis dilakukan mekanik menemukan bagian yang rusak selain dari estimasi awal, jika hal ini terjadi maka akan ada tambahan suku cadang atau tambahan pekerjaan yang harus dilaporkan kepada SA untuk kemudian memberikan informasi tambahan tersebut kepada pelanggan.

Dari semua detil servis mulai dari pekerjaan apa saja yang diberikan, suku cadang yang harus diganti, mekanik yang bertanggung jawab serta total biaya keseluruhan akan dikumpulkan untuk kepentingan pembuatan nota.

STIKOM

C. Output 1. Estimasi Biaya

Estimasi biaya dari proses diagnosa penentuan pekerjaan merupakan output yang akan diberikan kepada pelanggan. Estimasi biaya ini merupakan estimasi awal dari total biaya jasa dari pekerjaan yang diberikan dan biaya suku cadang yang harus diganti.

2. Estimasi Waktu

Estimasi waktu dari proses diagnosa penentuan pekerjaan merupakan output yang akan diberikan kepada pelanggan. Estimasi waktu ini merupakan estimasi awal dari total lama waktu pekerjaan yang diberikan.

3. Estimasi Pekerjaan

Estimasi pekerjaan dari proses diagnosa penentuan pekerjaan merupakan output yang akan diberikan kepada pelanggan. Estimasi pekerjaan ini merupakan estimasi awal dari pekerjaan yang akan diberikan kepada mobil pelanggan.

4. Estimasi Suku Cadang

Estimasi suku cadang dari proses diagnosa penentuan pekerjaan merupakan output yang akan diberikan kepada pelanggan. Estimasi suku cadang ini merupakan estimasi awal dari suku cadang yang harus diganti berdasarkan estimasi pekerjaan yang diberikan.

5. Laporan Transaksi

Laporan transaksi dari proses generate laporan merupakan output yang akan diberikan kepada Kepala Bengkel. Laporan transaksi berisi tentang semua

STIKOM

162

4.2.2 Pembahasan

Berdasarkan rumusan dan tujuan dari pembuatan aplikasi ini, dan setelah dilakukan uji coba dapat disimpulkan pembahasan dari pembuatan Tugas Akhir ini antara lain :

1. Berdasarkan keluhan pelanggan yang dicocokkan dengan rule sistem pakar, maka fungsi sistem pakar yang ada pada aplikasi dapat berjalan dengan baik dan dapat digunakan untuk menentukan pekerjaan yang harus dilakukan pada mobil, hal ini dapat dilihat dari hasil Test Case 32. Artinya dalam kasus untuk memberikan diagnosa dengan hasil output hanya 1, sistem pakar dengan metode forward chaining sudah efektif.

2. Untuk dapat menentukan estimasi suku cadang, estimasi total waktu pengerjaan dan estimasi total biaya adalah dengan membuat relasi dari masing-masing estimasi tersebut dengan data pekerjaan. Setiap pekerjaan mempunyai relasi dengan suku cadang dan jenis mobil yang akan diservis, sehingga pada saat pekerjaan sudah ditentukan maka suku cadang apa saja yang dibutuhkan dapat langsung diberikan. Lalu pada setiap pekerjaan mempunyai estimasi berapa lama pekerjaan itu selesai, sehingga jika ada lebih dari satu pekerjaan maka aplikasi dapat langsung menjumlahkan untuk menentukan estimasi lama waktu pengerjaan. Dan yang terakhir, setiap pekerjaan dan suku cadang mempunyai harga yang berbeda-beda, sehingga saat pekerjaan dan suku cadang sudah ditentukan maka aplikasi dapat langsung menjumlahkan keseluruhan harga untuk mendapatkan estimasi total biaya. Seperti pada hasil Test Case 21 menunjukkan bahwa estimasi suku

STIKOM

cadang otomatis langsung terisi beserta estimasi waktu & biaya setelah aplikasi menentukan pekerjaan yang akan diberikan, hal ini dimaksudkan agar pelanggan mengerti perkiraan berapa lama pelanggan harus menunggu serta total biaya yang harus dibayar. Seperti penjelasan sebelumnya, estimasi awal ini didapatkan setelah data pekerjaan sudah ditentukan, jadi apabila hasil diagnosa tidak ada kerusakan, maka estimasi awal tentang suku cadang yang dibutuhkan, estimasi waktu dan biaya tidak akan tampil.

3. Dari data estimasi awal, aplikasi dituntut untuk bisa mengolah data estimasi-estimasi tersebut ke dalam sistem transaksi bengkel. Pada hasil Test Case 22

– 23 menunjukkan bahwa aplikasi dapat menambahkan pekerjaan dan suku cadang apabila ditemukan kerusakan lagi pada saat proses service. Sedangkan pada hasil Test Case 24 – 25 menunjukkan bahwa aplikasi dapat menunjukkan daftar mobil yang sudah terdaftar ke dalam sistem transaksi bengkel, aplikasi juga membedakan status mobil dan memberikan fungsi untuk merubah status mobil apakah mobil sedang dalam tahap persiapan service yang berarti mobil sedang dalam tahap antri atau menunggu suku cadang, proses service yang berarti mobil sedang dalam tahap servis atau selesai service yang berarti mobil sudah selesai. Pada saat mobil dalam status selesai service, data mobil akan muncul pada bagian kasir sehingga pelanggan dapat membayar seperti yang terlihat pada hasil Test Case 26. Ini membuktikan bahwa aplikasi mampu untuk mengolah data estimasi awal ke dalam sistem transaksi bengkel dengan baik.

STIKOM

164

4. Dan yang terakhir mengacu pada data – data pada sistem transaksi bengkel, aplikasi harus mampu memberikan laporan – laporan yang dibutuhkan perusahaan. Pada Test Case 27 menampilkan laporan transaksi yang di dapatkan dari tabel transaksi dan juga tabel lainnya seperti tabel pekerjaan, suku cadang, pegawai dan pelanggan. Selanjutnya pada Test Case 28 menampilkan laporan loyalitas pelanggan yang didapatkan dari tabel transaksi dan pelanggan. Laporan beban kerja mekanik pada Test Case 29 didapatkan dari tabel transaksi dan pegawai. Sedangkan pada Test Case 30 menampilkan laporan pembelian suku cadang yang didapatkan dari tabel transaksi dan suku cadang. Dan yang terakhir laporan stok suku cadang yang dapat dilihaat pada Test Case 31 didapatkan dari tabel suku cadang. Seluruh laporan / output yang dibutuhkan perusahaan dapat ditampilkan dengan baik oleh aplikasi sehingga tujuan dari pembuatan aplikasi ini telah tercapai.

STIKOM

165 5.1 Kesimpulan

Setelah dilakukan uji coba dan evaluasi, maka dapat diperoleh kesimpulan sebagai berikut:

1. Aplikasi ini mampu memberikan solusi pekerjaan pada mobil yang di servis berdasarkan keluhan pelanggan dengan menggunakan sistem pakar, sehingga mampu mendukung keputusan service advisor dalam mendiagnosa.

2. Aplikasi ini mampu memberikan estimasi suku cadang yang dibutuhkan, estimasi total biaya dan estimasi waktu yang diperlukan berdasarkan pekerjaan yang telah ditentukan sehingga pelanggan mengerti perkiraan waktu untuk menunggu dan jumlah yang harus dibayar.

3. Aplikasi ini mampu mengolah data pekerjaan yang harus dilakukan pada mobil dan suku cadang yang diperlukan ke dalam sistem transaksi bengkel untuk kepentingan pembuatan laporan-laporan yang dibutuhkan perusahaan.

STIKOM

166

5.2 Saran

Adapun beberapa saran yang dapat diberikan kepada peneliti apabila ingin mengembangkan perangkat lunak yang telah dibuat ini agar menjadi lebih baik adalah sebagai berikut:

1. Aplikasi sistem pakar ini dapat dikembangkan agar bisa digunakan untuk umum, sehingga pelanggan dapat mengira-ngira jenis pekerjaan / tindakan yang harus dilakukan pada mobilnya, suku cadang yang yang harus diganti serta perkiraaan biaya dan waktu pengerjaan berdasarkan keluhan pelanggan.

2. Aplikasi sistem pakar ini dapat dikembangkan agar bisa digunakan untuk umum dengan berbasis web atau mobile application untuk berbagai macam platform smartphone seperti Android, Blackberry, Windows

Mobile dan iOS.

3. Aplikasi administrasi pada bengkel masih belum lengkap karena berfokus pada sistem pakar, sehingga bisa dikembangkan dengan menambahkan proses penjualan suku cadang, proses pengadaan suku cadang dan penghitungan laba-rugi yang lebih detail.

STIKOM

167

Dologite, D. (1993). Developing Knowledge-Based System Using VP-Expert. New York: Macmillan Publishing Company.

Fathansyah. (2007). Basis Data. Bandung: Informatika.

Gonzales, A. I., & Dankel, D. D. (1993). The Engineering of Knowledge Based

System. New Jersey: Prentice Hall.

Irawan, J. (2007). Buku Pegangan Kuliah Sistem Pakar. Surabaya: Sekolah Tinggi Manajemen Informatika & Teknik Komputer Surabaya .

Kadir, A. (2008). Dasar Pemrograman Web Dinamis Dengan PHP - Edisi Revisi. Yogyakarta: Andi.

KSS, T. (2007). Mengelola Bengkel Mobil. Jakart: Dinamika Media. Kusrini. (2006). Sistem Pakar, Teori dan Aplikasi. Yogyakarta: Andi. Robbie. (2007, 03). Apa itu Internet ? Dipetik 08 23, 2011, dari

www.robbiesfamily.net: http://www.robbiesfamily.net/2007/03/teori-intranet-1-apa-itu-intranet.html

Sommerville, I. (2003). Rekayasa Perangkat Lunak Edisi ke-6. Jakarta: Erlangga. Statistik, B. P. (2011). Perkembangan Jumlah Kendaraan Bermotor Menurut

Jenis tahun 1987-2011. Dipetik Maret 8, 2013, dari http://www.bps.go.id:

http://www.bps.go.id/tab_sub/view.php?tabel=1&daftar=1&id_subyek=17&notab =12

Zeithaml, V. A., & Bitner, M. J. (2002). Service Marketing. New York: McGraw Hill Inc.

STIKOM