Rancang Bangung Aplikasi Bank Soal

BAB IV

ANALISIS DAN PERANCANGAN SISTEM

4.1 Metode Pengumpulan Data

Metode pengumpulan data yang digunakan dalam

penyusunan laporan PKL (Praktek Kerja Lapangan) ini

adalah:

4.1.1 Observasi

Observasi atau pengamatan langsung adalah

pengumpulan data dimana peneliti atau kolaboratornya

mencatat informasi sebagaimana yang mereka saksikan

selama penelitian (Gulo, 2005).

Pengumpulan data dilakukan dengan melihat

langsung proses dan kegiatan bisnis yang berjalan

pada PT Aplikanusa Lintasarta. Pada tanggal 1

Februari 2012 – 29 Februari 2012, dilakukan 4 hari

dalam seminggu selama 1 bulan yang bertempat di Jl.

T.B. Simatupang (R.A Kartini) Kav.10 Jakarta

Selatan, 12430. Hasil yang akan dicapai adalah

melihat proses bisnis yang berjalan dan segala

kegiatan yang dilaksanakan. Kegiatan pengamatan

langsung ini dilakukan di bawah pengawasan Bapak

48

Kadek Agus Yudhana selaku Asisten Manajer Gold

Divisi Customer Relationship dan Bapak Abdurrahim Fachri

Nasution selaku Asisten Manajer Silver Divisi

Customer Relationship PT Aplikanusa Lintasarta.

Beliau memberikan data-data yang dibutuhkan

untuk menganalisis dan merancang perbaikan aplikasi

helpdesk pada portal ISDS (Integrated Service Delivery

System). Seperti data bisnis proses dalam pemakaian

aplikasi ISDS dari mulai pre sales service hingga after

sales service, penjelasan seputar pemakaian aplikasi

ISDS khususnya pada aplikasi helpdesk, serta data-

data profil perusahaan.

4.1.2 Wawancara

Wawancara adalah proses memperoleh keterangan

untuk tujuan penelitian dengan cara melakukan tanya

jawab, sambil bertatap muka antara si penanya atau

pewawancara dengan si penjawab atau responden

dengan menggunakan alat yang dinamakan interview guide

(Nazir, 2005).

Metode wawancara yang digunakan untuk

mendapatkan data adalah dengan cara mengajukan

pertanyaan kepada pihak yang terlibat langsung

dengan aplikasi helpdesk ISDS (Integrated Service and

Delivery System) khususnya pada Divisi CR (Customer

49

relationship) yang melayani penanganan aduan gangguan

pelanggan.

Pihak yang terkait pada wawancara ini adalah

pembimbing lapangan di perusahaan tempat saya PKL

yaitu Bapak Kadek Agus Yudhana dan Bapak Abdurrahim

Fachri Nasution. Pertanyaan yang saya ajukan ke

Bapak Fachri diantaranya adalah “Apakah aplikasi

helpdesk pada portal ISDS ini mampu melayani

penanganan pengaduan pelanggan dengan baik? sebagai

salah satu asisten manajer CAR ini pun menjawab

“Saat ini aplikasi helpdesk ISDS berjalan cukup

baik, namun masih ada beberapa kekurangan yang

terdapat pada aplikasi ini diantaranya adalah

aplikasi ini belum memiliki sistem alert sebagai

reminder (pengingat) kepada helpdesk/CAR untuk

melakukan update penanganan gangguan kepada

pelanggan.

50

4.1.3 Studi Pustaka

Studi pustaka dilakukan dengan mempelajari

teori-teori yang berhubungan dengan sistem aplikasi

helpdesk. Teori-teori tersebut berasal dari buku,

jurnal, internet, maupun majalah. Buku-buku yang

digunakan antara lain Petunjuk Penggunaan Sistem Remedy

Helpdesk, (2004), PT. RTM, Pengenalan Teknologi

Informasi, Metode Desain dan Analisis Sistem dan

lain sebagainya.

4.2 Indentifikasi dan Seleksi Proyek

Saat ini PT Aplikanusa Lintasarta, Jakarta Selatan

telah menerapkan sistem terintegrasi yang dinamakan ISDS

(Integrated Service and Delivery System) yang digunakan untuk

beberapa divisi. Divisi CR (Customer Relationship)

menggunakan sistem ini sebagai sistem helpdesk untuk

penanganan aduan gangguan. Pada sistem aplikasi helpdesk,

masih terdapat beberapa kekurangan yang mampu

menyebabkan pelayanan kepada pelanggan kurang maksimal,

diantaranya adalah belum adanya alert untuk mengingatkan

helpdesk/CAR agar melakukan update perkembangan penanganan

aduan gangguan ke pelanggan dan sistem pengiriman

notifikasi email otomatis yang berfungsi untuk

mengirimkan pemberitahuan ke email helpdesk/CAR agar51

segera melakukan update penanganan gangguan ke pelanggan

dan segera melakukan punutupan tiket (close ticket) setelah

melewati batas ketentuan perusahaan. Oleh karena itu,

untuk mengoptimalkan pelayanan penanganan aduan gangguan

kepada pelanggan dibutuhkan suatu perbaikan terhadap

aplikasi yang telah berjalan sehingga pelayanan kepada

pelanggan dapat optimal.

4.3 Inisiasi dan Perencanaan Sistem

Pada tahap ini ada beberapa persiapan yang perlu

dilakukan dalam menganalisis dan merancang aplikasi

helpdesk, antara lain:

a. Profil perusahaan PT Aplikanusa Lintasarta, yaitu

uraian mengenai latar belakang, visi, misi, dan core

values perusahaan.

b. Identifikasi masalah, yaitu mengidentifikasi masalah-

masalah yang terdapat pada aplikasi helpdesk yang

sedang berjalan, sehingga dapat memberikan solusi

atau pemecahan masalah untuk perbaikan dan

pengembangan sistem. Identifikasi masalah pada sistem

yang berjalan diantaranya adalah:

1. Sistem aplikasi helpdesk belum memiliki fitur yang

mampu mengirimkan notifikasi secara langsung ke

52

email pelanggan setelah helpdesk/CAR membuat ataupun

meng-update tiket pelanggan.

2. Sistem aplikasi helpdesk belum memiliki sistem alert

untuk mengingatkan helpdesk/CAR yang seringkali lupa

untuk melakukan update informasi ke pelanggan dan

melakukan close ticket apabila dalam kurun waktu lebih

dari 2 jam, helpdesk/CAR belum memberikan informasi

ke pelanggan.

3. Sistem aplikasi helpdesk belum memiliki sistem

automation (otomasi) yang berguna untuk mengirimkan

notifikasi ke email helpdesk/CAR yang belum melakukan

close ticket dan update penanganan gangguan jaringan ke

pelanggan apabila dalam jangka waktu lebih dari 4

jam, helpdesk/CAR belum melakukan update penanganan

gangguan pelanggan dan belum melakukan close ticket yang

dapat dapat menyebabkan laporan SLA (Service Level

Agreement) pelanggan tidak muncul dan dapat

mengalami lompat bulan.

c. Lingkup sistem, yaitu menentukan batasan ruang

lingkup sistem yang akan dibangun. Lingkup sistem

yang akan dibangun di antaranya adalah:

a. Sistem dapat mengolah data tiket, data

pelanggan, data jaringan, data alert, data trigger,

data otomasi, data penanggung jawab.

53

b. Sistem yang akan dikembangkan dapat digunakan

untuk memperbaiki sistem aplikasi helpdesk yang

sudah ada.

c. Tujuan sistem, yaitu menentukan untuk apa dan

untuk siapa sistem ini dibangun. Perancangan

perbaikan aplikasi sistem helpdesk ini bertujuan

untuk memberikan solusi optimal terhadap

permasalahan-permasalahan yang terjadi selama

ini pada aplikasi helpdesk di PT Aplikanusa

Lintasarta.

4.4 Analisis

4.4.1 Bisnis Proses Sistem Aplikasi ISDS pada PT

Aplikanusa Lintasarta

Gambar 4.1 Bisnis Proses Sistem Aplikasi ISDS PT

Aplikanusa Lintasarta

54

Sistem ISDS merupakan suatu portal web yang

terintegrasi dengan beberapa divisi di lingkup PT

Aplikanusa Lintasarta, seperti Divisi CR (Customer

relationship), Divisi Service delivery/ Divisi Pasang Baru

(PSB), Divisi Operasional Harian (Ophar), serta

Divisi Keuangan. Sistem ISDS ini hanya dapat

dijalankan pada jaringan internal perusahaan dan

yang dapat mengakses sistem ini hanyalah orang-

orang yang bekerja menggunakan sistem ini dan telah

terdaftar, dalam hal ini adalah karyawan PT

Aplikanusa Lintasarta itu sendiri, baik dari kantor

pusat maupun dari kantor-kantor cabang yang saling

terhubung.

4.4.1.1 Proses Online Billing Jaringan Dari Pre Sales Service

hingga After Sales Service

55

Gambar 4.2 Flowchart Online Billing Jaringan

Penjelasan Proses Online Billing Jaringan

1. Pelanggan menghubungi bagian sales untuk proses

pemasangan baru jaringan

2. Sales memberikan Form Pemasangan Baru (FPB) kepada

pelanggan. Form Pasang Baru (FPB) mencakup alamat

pelanggan, Ketentuan RFS (Ready for Service) yang disetujui

56

oleh pelanggan dan penyedia jasa, Besaranya bandwith

yang akan dipasang, serta PIC Remote (Personel In Charge).

3. Bagian Dukjul (Dukungan Penjualan) pada sales memproses

data-data yang telah diberikan untuk kemudian diberikan

ke Divisi Service Delivery.

4. DCO (Delivery Control Officer) yang merupakan bagian dari

Divisi Service Delivery bertugas memasukan data pelanggan

baru yang telah diperoleh ke dalam FPB Online pada

sistem ISDS.

5. Bagian Product Management akan melakukan proses verifikasi

RFS (Ready for Service), Kebutuhan kapasitas, Alokasi Datek

(Data Telekomunikasi).

6. Setelah segala keperluan menyangkut survey awal selesai,

maka terbitlah SPK (Surat Perintah Kerja) dan kegiatan

instalasi jaringan oleh Divisi Service Delivery (Pasang Baru)

dilakukan.

7. Proses Aktivasi jaringan mulai dilakukan setelah BAO

(Berita Acara Operasional) terbit dan secara otomotis

online billing pun mulai berjalan.

8. Pada tahapan ini jaringan pelanggan sudah dapat

digunakan dengan status online billing yang berarti jaringan

masih ada garansi selama 2 minggu atau 14 hari.

9. Helpdesk/CAR akan melakukan konfirmasi ke pelanggan bahwa

proses pemasangan baru jaringan telah berhasil dan

jaringan telah dapat digunakan oleh pelanggan.

57

4.4.1.2 Proses Cabut Jaringan

58

Gambar 4.3 Flowchart Cabut Jaringan

Penjelasan Proses Dalam Cabut Jaringan Pelanggan

59

1. Pelanggan menghubungi helpdesk/CAR untuk menangani aduan.

2. Helpdesk/CAR merespon aduan pelanggan

3. Helpdesk/CAR melakukan verifikasi data pelanggan guna

memperoleh nomor jaringan pelanggan melalui aplikasi

ISDS.

4. Jika aplikasi ISDS tidak mampu melacak pelanggan

berdasarkan nomor jaringan, nama perusahaan, dan alamat,

maka helpdesk/CAR akan menghubungi bagian sales untuk

menanyakan nomor jaringan, sebab pada awal pemasangan

jaringan, bagian sales yang langsung berhubungan dengan

pelanggan dan telah memasukan data pelanggan ke sistem

penjualan.

5. Pelanggan ingin melakukan cabut jaringan, maka

helpdesk/CAR akan mengembalikan permasalahan ke Divisi

Service Delivery/ Pasang Baru.

6. Pelanggan akan diberikan Form Permintaan Cabut (FPC)

untuk diisi dari bagian sales.

7. Setelah diisi form ketentuanya, maka akan diterbitkan

SPK (Surat Perintah Kerja) sebagai surat resmi dari

perusahaan yang menyampaikan bahwa jaringan yang

dipasang di tempat pelanggan akan dilakukan proses

pencabutan. Ada beberapa alasan mengapa pelanggan

melakukan proses cabut jaringan, diantaranya adalah:

60

Masa kontrak antara pelanggan dengan PT Aplikanusa

Lintasarta telah habis. Perjanjian pemasangan

jaringan biasanya selama 1 tahun.

Jaringan yan bermasalah, sehingga mengakibatkan

pelanggan memutuskan untuk mencabut jaringan.

Ditutupnya cabang perusahaan pelanggan.

Jaringan sudah tidak digunakan.

Harga yang semakin meningkat utnuk pemasangan

jaringan.

8. Dengan adanya SPK dari perusahaan pula maka NMS (Network

management system) dapat dilakukan proses shutdown dan

deinstalasi jaringan.

4.4.1.3 Proses Mutasi Jaringan

61

Gambar 4.4 Flowchart Mutasi Jaringan

Penjelasan Proses Mutasi Jaringan Pelanggan

62

1. Pelanggan menghubungi helpdesk/CAR untuk menangani

permasalahan.

2. Helpdesk/CAR merespon aduan pelanggan

3. Helpdesk/CAR melakukan validasii data pelanggan guna

memperoleh nomor jaringan pelanggan melalui sistem ISDS.

4. Jika aplikasi ISDS tidak mampu melacak pelanggan

berdasarkan nomor jaringan, nama perusahaan, dan alamat,

maka helpdesk/CAR akan menghubungi bagian sales untuk

menanyakan nomor jaringan, sebab pada awal pemasangan

jaringan, bagian sales yang langsung berhubungan dengan

pelanggan dan telah memasukan data pelanggan ke sistem

penjualan.

5. Pelanggan ingin melakukan mutasi jaringan, maka

helpdesk/CAR akan mengembalikan permasalahan ke Divisi

Service Delivery/ Pasang Baru

6. Pelanggan akan diberikan Form Permintaan Perubahan (FPP)

untuk diisi.

7. Setelah diisi form ketentuanya, maka akan diterbitkan

SPK (Surat Perintah Kerja) sebagai surat resmi dari

perusahaan yang menyampaikan bahwa jaringan yang

dipasang di tempat pelanggan akan dilakukan proses

mutasi. Ada beberapa alasan mengapa pelanggan melakukan

proses mutasi, diantaranya adalah:

Pelanggan menginginkan upgrade ataupun downgrade

kecepatan jaringan

63

Mutasi alamat, yakni adanya perubahan alamat

perusahaan pelanggan

8. Dengan adanya SPK dari perusahaan pula maka akan ada

proses provisioning. Proses provisioning diantaranya adalah

instalasi, aktivasi jaringan, dan lain-lain.

9. Setelah semua prosedur selesai maka proses mutasi pun

berhasil.

4.4.2 Analisa Sistem yang Sedang Berjalan

4.4.2.1 Aplikasi Helpdesk ISDS (Integrated Service Delivery

System) PT Aplikanusa Lintasarta

Pada dasarnya, aplikasi ISDS hanya dapat

dijalankan pada jaringan internal PT Aplikanusa

Lintasarta dan yang berhak menggunakan hanyalah

orang-orang yang dalam keseharian bekerja dengan

sistem ini dan telah terdaftar pada database

sistem, dalam hal ini adalah karyawan PT Aplikanusa

Lintasarta itu sendiri, baik karyawan dari kantor

pusat maupun dari kantor-kantor cabang yang saling

terhubung. Aplikasi ISDS ini dapat diakses oleh

berbagai divisi, diantaranya adalah Divisi Customer

Relationship, Divisi Service Delivery, Divisi Operasional

Harian, dan Divisi Keuangan. Walaupun semua divisi

tersebut mampu mengakses halaman yang sama, namun

64

tetap saja mereka hanya dapat menggunakan halaman-

halaman pada aplikasi yang menjadi tugas mereka,

seperti Divisi CR yang terdiri dari helpdesk/CAR,

walaupun mereka dapat melihat pekerjaan-pekerjaan

yang dilakukan oleh divisi lain, namun karena

mereka tidak mengerti tugas yang dilakukan oleh

divisi lain, maka halaman tersebut tidak perlu

dibuka, cukup membuka halaman tempat mereka

bekerja.

Helpdesk/CAR menggunakan aplikasi ISDS ini

untuk menangani keluhan pelanggan terkait dengan

gangguan komunikasi data dan internet, jadi apabila

pelanggan mengadukan hal-hal diluar gangguan, maka

tidak diproses oleh helpdesk/CAR dan akan dilempar

ke divisi lain sesuai dengan masalah yang dihadapi

pelanggan. Seorang helpdesk/CAR mampu memasukan data

keluhan pelanggan, membuat tiket aduan, melakukan

eskalasi masalah, monitoring gangguan, dan membuat

laporan gangguan. Berikut ini merupakan gambar dari

sistem ISDS yang terdapat pada PT Aplikanusa

Lintasarta.

65

Gambar 4.7 Kolom Untuk Melakukan Validasi Data

Pelanggan

Gambar 4.8 Kolom Pencarian History Gangguan Pelanggan

66

Gambar 4.9 Log Gangguan pada Aplikasi Helpdesk ISDS

4.4.2.2 Proses Penanganan Aduan Gangguan Dengan Aplikasi

Helpdesk ISDS

67

Gambar 4.10 Penanganan Aduan Gangguan Dengan Aplikasi

Helpdesk ISDS

68

Penjelasan Prosedur Dalam Penanganan Aduan Gangguan

1. Pelanggan menghubungi helpdesk/CAR untuk menangani

keluhan.

2. Helpdesk/CAR merespon keluhan pelanggan yang diterima

melalui telepon ataupun email. Keluhan yang dialami

pelanggan berkaitan dengan permasalahan jaringan

komunikasi data.

3. Helpdesk/CAR memverifikasi data pelanggan dengan

menanyakan nama perusahaan, alamat perusahaan, dan lain

sebagainya untuk memperoleh nomor jaringan pelanggan

yang di input pada sistem aplikasi ISDS.

4. Jika aplikasi tidak mampu melacak pelanggan nomor

jaringan pelanggan, maka helpdesk/CAR akan menghubungi

sales untuk menanyakan nomor jaringan, sebab pada awal

pemasangan jaringan, bagian sales yang langsung

berhubungan dengan pelanggan dan sales telah memasukan

data pelanggan ke sistem penjualan.

5. Setelah proses verifikasi data pelanggan selesai

kemudian helpdesk/CAR mengidentifikasi gangguan jaringan

pelanggan, misalnya link pelanggan mengalami

penurunan/down atau aplikasi lambat atau tidak bisa

mengakses ke link internasional.

6. Setelah teridentifikasi masalah yang dikeluhkan oleh

pelanggan, maka helpdesk/CAR akan membuat tiket aduan dan

69

secara otomatis pelanggan akan memperoleh nomor tiket.

Status tiket terdiri dari :

a. Open ticket adalah tiket yang sedang dilakukan proses

penanganan aduan gangguan sesuai komitmen service level

agreement (SLA).

b. Pending ticket adalah tiket yang sedang dalam proses

penanganan tetapi ditunda kerena beberapa hal,

misalnya kendala transportasi, cuaca, kendala

teknis maupun non teknis.

c. Stop clock adalah sistem yang diperuntukan atas

kesepakatan dengan pelanggan jika terjadi hal

diluar ketentuan teknis, misalnya dilokasi sedang

mengalami musibah, mati listrik, kendala

transportasi. Hal ini dilakukan agar counter durasi

perbaikan sesuai dengan service level agreement.

d. Close ticket adalah suatu tiket yang sudah selesai

ditangani oleh helpdesk/CAR maupun teknisi.

7. Setelah memasukan tiket aduan, maka status tiket akan

berubah menjadi open ticket.

8. Kemudian dilakukan proses pengecekan oleh bagian terkait

sesuai dengan masalah dan jenis jaringannya.

9. Apabila hasil pengecekan ternyata jaringan pelanggan

normal maka helpdesk/CAR akan melakukan close ticket dan log

gangguan akan ter-update, lalu helpdesk/CAR akan melakukan

update informasi ke pelanggan.

70

10. Namun, jika ternyata setelah dilakukan pengecekan

masih terdapat masalah, maka helpdesk/CAR akan melakukan

first level handling, dimana helpdesk/CAR akan melakukan

koordinasi dengan pelanggan untuk melakukan pengecekan

NMS (Network Management System) pelanggan serta pengecekan

perangkat yang dipasang di tempat pelanggan yang dapat

dilakukan dengan melakukan reset modem pelanggan.

11. Apabila setelah melakukan reset modem jaringan

belum normal, maka helpdesk/CAR akan melakukan second level

handling dengan men-dispatch tiket ke divisi operasional

harian. Divisi ini terlebih dahulu akan menetapkan tugas

kepada teknisi dan kemudian mengirim teknisi ke lokasi

pelanggan untuk mengecek lebih lanjut gangguan jaringan

pelanggan dan kemudian akan memonitor gangguan

pelanggan.

12. Setelah masalah terselesaikan, maka tiket akan

dikembalikan ke helpdesk/CAR yang bersangkutan. Kemudian

helpdesk/CAR akan melakukan close ticket dan mengirim update

informasi ke pelanggan melalui email ataupun telepon.

4.4.2.3 Eskalasi

Eskalasi adalah suatu kejadian dimana ketika bagian

helpdesk tidak mampu melayani pelayanan pengaduan

gangguan pelanggan dan belum mampu memberikan alternatif

solusi kepada pelanggan dalam jangka waktu lebih dari 2

71

jam, maka bagian helpdesk akan melakukan eskalasi atau

proses untuk meningkatkan penanganan ke level yang

lebih tinggi. Berikut ini merupakan tabel eskalasi

berdasarkan waktu penanganan.

Tabel 4.1 – Tabel Eskalasi

Sumber : Dokumentasi PT Aplikanusa Lintasarta

Level Waktu Eskalasi0 0 s/d 0.25 Lintasarta Customer Care1 0.25 s/d 4 Customer relationship

Management2 4 s/d 6 AVP Customer relationship

3 6 s/d 8 VP Customer relationship Group4 8 s/d 24 SVP Customer relationship

Group5 > 24 Business Director

4.4.2.4 Teknologi Pengolahan Data yang Digunakan

Teknologi pengolahan data yang digunakan untuk

menjalankan aplikasi helpdesk ISDS di PT Aplikanusa

Lintasarta antara lain:

1. Hardware

a) Processor : Intel Pentium 4 1.80 Ghz

b) RAM : 512 MB

72

c) Harddisk : 40 GB

d) Floopy Disk : -

e) Mouse : Scrool

f) Keyboard : Logitech

g) Monitor : LCD 15” Samsung

h) Telepon PABX : Notel Network

2. Software

a) Sistem Operasi : Windows XP

b) Aplikasi Program : Microsoft Office 2007,

Mozilla Firefox, Microsoft Outlook.

4.4.3 Analisa Sistem Usulan

Sistem yang diusulkan adalah dengan menambahkan

beberapa fitur tambahan pada aplikasi helpdesk ISDS.

Penjelasan pada gambaran analisa sistem yang diajukan

adalah:

1) Sistem alert. Alert ini akan berjalan ketika helpdesk/CR

tidak melakukan update informasi ke pelanggan selama

lebih dari 2 jam, alert juga akan berjalan apabila

helpdesk/CAR belum melakukan close ticket selama lebih dari

2 jam setelah tiket terpecahkan (solved) dan setelah

dilakukan update informasi ke pelanggan.Tiket yang

belum ditutup dapat menyebabkan tidak munculnya

laporan bulanan dan waktu respon terhadap penangan

pelanggan yang melebihi SLA (Service Level Agreement).

73

2) Sistem lain yang diusulkan adalah dengan menambahkan

sistem trigger (pemicu), sistem ini dapat mengirimkan

notifikasi otomatis ke email pelanggan secara

langsung tanpa butuh pengaturan waktu sebelumnya.

Salah satu contoh notifikasi yang diusulkan adalah

notify requester of received ticket, dengan adanya notifikasi

ini maka secara otomatis sistem trigger akan langsung

mengirimkan notifikasi ke email pelanggan dan

memberitahuan ke pelanggan bahwa aduan mereka telah

diterima dan telah menjadi tiket.

3) Sistem automation (otomasi), sistem ini hampir sama

dengan sistem trigger (pemicu), namun yang membedakan

adalah sistem ini membutuhkan pengaturan waktu pada

kondisi tertentu. Dalam kasus ini PT Aplikanusa

Lintasarta menginginkan agar sistem otomasi ini dapat

mengirimkan notifikasi ke email helpdesk/CAR ketika

dalam jangka waktu lebih dari 4 jam helpdesk/CAR tidak

segera melakukan update informasi ke pelanggan dan

melakukan close ticket.

4.4.3.1 Sistem Usulan Trigger, Alert, dan Otomasi

74

75

Gambar 4.11 Sistem Usulan Trigger, Alert, dan Otomasi

76

4.5 Desain Sistem

Dalam menerapkan sistem perbaikan pada aplikasi

helpdesk ISDS, alur proses digambarkan dengan menggunakan

tools DFD (Data Flow Diagram) seperti Context diagram, Zero

diagram, diagram level 1, dan lain-lain (Jones,2008).

4.5.1 Rancangan Diagram Aliran Data (Data Flow Diagram)

4.5.1.1 Rancangan Diagram Konteks (Level 0)

Diagram konteks menggambarkan proses

sistem secara umum. Diagram ini dibuat untuk

menggambarkan sumber serta distribusi data

yang akan diproses atau dengan kata lain

diagram tersebut untuk menggambarkan secara

lebih menyeluruh dari keseluruhan sistem yang

ada, khususnya pada kasus ini adalah aplikasi

helpdesk ISDS. Diagram konteks dapat dilihat

pada Gambar 4.12.

77

Gambar 4.12 Rancangan Diagram Konteks (Level 0)

Diagram konteks (level 0) menggambarkan

bahwa sistem sebagai proses berinteraksi

dengan lima entitas yaitu helpdesk/CAR,

operasional harian, teknisi lapangan, manajer,

dan pelanggan. Hal yang pertama kali dilakukan

oleh ketiga entitas tersebut (helpdesk/CAR,

operasional harian, dan manajer) agar dapat

mengakses aplikasi helpdesk adalah dengan

memasukan user name dan password masing-masing.

Jika berhasil masuk ke sistem,maka sistem akan

masuk ke menu utama. Apabila terdapat

pelanggan yang mengeluhkan gangguan kepada

helpdesk/CAR, maka sebelum melakukan proses

78

lebih lanjut helpdesk/CAR akan melakukan

validasi data pelanggan yang sebelumnya telah

tersimpan di dalam database pelanggan yang

nantinya akan menghasilkan keluaran berupa

informasi detail pelanggan. Keluhan pelanggan

tersebut kemudian akan menjadi tiket.

Helpdesk/CAR lalu akan melakukan pengaturan

terhadap fungsi trigger, alert, dan otomasi pada

sistem. Trigger yang telah dilakukan

pengaktifan, maka akan langsung mengirimkan

notifikasi ke email pelanggan yang

memberitahukan bahwa tiket telah dibuat.

Helpdesk/CAR kemudian melakukan first level

handling, apabila masalah gangguan jaringan

pelanggan belum bisa ditangani, maka

helpdesk/CAR akan melakukan Second Level Handling,

dimana tiket dilempar ke Divisi Operasional.

Divisi ini yang kemudian akan menugaskan

teknisi lapangan untuk melihat masalah

jaringan di tempat pelanggan. Jika masalah

telah ditemukan, maka teknisi lapangan akan

memberikan informasi solusi ke Divisi

Operasional. Lalu Divisi Operasional akan

menyerahkan kembali tiket tersebut ke

helpdesk/CAR. Helpdesk/CAR kemudian melakukan

79

update tiket ke pelanggan dan dilanjutkan

dengan melakukan close ticket.

Pada tiap bulan helpdesk/CAR akan

menyerahkan laporan rekapitulasi gangguan

jaringan pelanggan kepada manajer sehingga

manajer mampu memetakan apa saja gangguan-

gangguan yang sering dialami oleh pelanggan

dan dapat memberikan solusi lebih lanjut dalam

penanganannya.

4.5.1.2 Rancangan Diagram Zero (Level 1)

80

Gambar 4.13 Rancangan Diagram Zero (Level1)

Diagram zero (level 1) menunjukkan fungsi-

fungsi utama atau proses yang ada, aliran

data, external entity, dan data store yang digunakan

pada sistem yang diusulkan. Dalam diagram zero

(level 1) pada sistem yang diusulkan terdapat:

1. Empat proses, yaitu login, pengolahan

data keluhan pelanggan, pengolahan81

trigger, alert, dan otomasi, dan pembuatan

laporan.

2. Lima data store, yaitu login, pelanggan,

tiket, solusi, dan trigger, alert, otomasi.

3. Lima external entity seperti helpdesk/CAR,

operasional harian, teknisi lapangan,

manajer, dan pelanggan.

4.5.1.3 Rancangan Diagram Detail Level 1

Gambar 4.14 Diagram Detail Level 1

82

Pada gambar Diagram Detail level 1 proses

login digambarkan arus data secara lebih

detail dan terperinci lagi dari tahapan proses

yang ada dalam diagram nol. Pada diagram

diatas dijelaskan bahwa ada tiga entitas yang

berinteraksi langsung dengan aplikasi helpdesk

ISDS, diantaranya adalah helpdesk/CAR, Divisi

Operasional Harian, dan manajer. Untuk

melakukan login ke aplikasi, ketiga entitas

tersebut harus memasukan username dan password

yang telah diberikan. Hal ini dilakukan agar

data-data yang terdapat pada sistem dapat

terjaga dan tidak menjadi konsumsi masyarakat

luas


83

Gambar 4.15 Rancangan Diagram Detail Level 2

Pada rancangan diagram detail level 2 ini

dijelaskan proses penangana keluhan pelanggan yang

dimulai dari validasi data pelanggan dimana

sebelumnya data pelanggan telah terinput ke dalam

database pelanggan kemudian dilanjutkan dengan input

keluhan pelanggan yang akan disimpan ke dalam

database tiket, dilanjutkan dengan input data

solusi. Data solusi diperoleh dari divisi

operasional harian yang telah melakukan pengecekan

84

lapangan untuk menangani gangguan jaringan

pelanggan dan hasil yang diperoleh kemudian akan

diteruskan ke helpdesk/CAR untuk di input ke database

solusi sebelum pada akhirnya solusi tersebut

disampaikan ke pelanggan. Setelah masalah

terpecahkan, maka helpdesk/CAR akan melakukan tutup

tiket (close ticket).


85

Gambar 4.16 Rancangan Diagram Detail Level 3

Pada diagram detail level 3 ini menjelaskan

tentang langkah-langkah pengaturan trigger, alert, dan

otomasi. Langkah pertama untuk menambahkan trigger

86

yang akan diimplementasikan pada tiket adalah

dengan memilih notifikasi yang akan dijalankan. Ada

beberapa pilihan notifikasi yang tersedia pada

aplikasi, diantaranya adalah Notify requester of received

ticket, Notify requester of comment update, Notify requester of

solved request, Notify asignee of comment update, Notify asignee

of assignment, Notify asignee of reopened ticket,Notify group of

assignment,Notify all agents of received request. Pada aplikasi

helpdesk ISDS, notifikasi yang digunakan untuk

memberikan notifikasi ke pelanggan adalah notify

requester of received ticket dan notify assignee of assignment,

namun helpdesk/CAR yang bertanggung jawab dapat

menambahkan notifikasi lainnya ke dalam aplikasi

dan tentunya harus disesuaikan dengan kebutuhan.

4.5.2 Kamus Data

Kamus data atau Data Dictionary adalah katalog fakta

tentang data dan kebutuhan informasi. Dengan menggunakan

kamus data analisis sistem dapat mendefinisikan aliran

data yang ada di sistem dengan lengkap. Kamus data

dibuat pada tahap analisis sistem dan digunakan dengan

baik pada tahap analisis maupun tahap perancangan

sistem. Kamus data menggambarkan data (dokumen) yang

mengalir dari suatu proses ke proses lainnya, dari

entitas luar ke proses atau dari proses ke entitas luar.

87

Arus data ini dibutuhkan baik oleh sistem maupun

entitas. Berikut ini adalah kamus data dari masing-

masing arus data yang mengalir pada aplikasi helpdesk ISDS

:

tb_login :

{ @id_login + username + password }ⁿ

@id_login : *id untuk mengurut record member (auto

increment)*;1 {integer}10

username : *username*;1{varchar}10

password : *password*;1{varchar}8

tb_tiket :

{ @no_tiket + info_tiket + stat_update + tgl_mulai +

tgl_selesai + durasi + masalah + no_jar + nama_jar +

kelas_jaringan + nama_pelanggan + kelas_pelanggan + nama_pj +

kelas_pj }ⁿ

@no_tiket: *nomor untuk mengurut nomor tiket aduan (auto


info_tiket: *info tiket*;1{varchar}20

stat_update: *status update tiket aduan pelanggan*;1

{varchar}20

tgl_mulai: *tanggal mulai penanganan aduan gangguan*;1 {date

and time}

88

tgl_selesai: *tanggal selesai penanganan aduan*;1 {date and

time}

durasi : *durasi penanganan aduan*;1 {integer}10

masalah: *masalah aduan*;1 {varchar}200

no_jar: *nomor jaringan pelanggan*;1{integer}10

nama_jaringan : *nama jaringan pelanggan*;1{varchar}30

kelas_jaringan: *kelas jaringan pelanggan*;1{varchar}10

nama_pelanggan: *nama pelanggan*; 1{integer}25

kelas_pelanggan: *kelas pelanggan*;1{varchar}10

nama_pj: *nama penanggung jawab*;1 {varchar}20

kelas_pj: *kelas penanggung jawab*;1{integer}10

tb_pelanggan :

{@id_pelanggan + nama_pelanggan + alamat_pelanggan +

kelas_pelanggan + email + telp }ⁿ

@id_pelanggan : *ID untuk mengurut pelanggan perusahaan (auto


nama_pelanggan : *nama pelanggan perusahaan;1*{varchar}25

alamat_pelanggan : *alamat pelanggan perusahaan;1*{varchar}50

kelas_pelanggan : *tipe pelanggan perusahaan (bronze,silver atau

platinum};1*{varchar}10

email : *alamat email pelanggan*;1{varchar}25

telp : *telepon pelanggan*;1 {integer}15

tb_jaringan :89

{@id_jaringan + nama_jaringan + kelas _jaringan}ⁿ

@id_jaringan : *ID untuk mengurut nomor jaringan pelanggan

(auto increment)*;1{integer}10

nama_jaringan : *nama jaringan pelanggan;1*{varchar}20

kelas_jaringan : *kelas jaringan;1*{varchar}10

tb_alert:

{@id_alert + no_tiket + aktivasi}ⁿ

@id_alert : *ID untuk mengurut nomor alert (auto

increment)*;1{integer}10

aktivasi : *mengaktifkan atau menon aktifkan alert*;1

{varchar}10

no_tiket : *nomor tiket pelanggan*;1{integer}10

info_tiket : *info tiket pelanggan*;1{varchar}20

tb_trigger :

{@id_trigger + notifikasi + judul + kondisi + aksi + pesan +

no_tiket + info_tiket }ⁿ

@id_trigger : *ID untuk mengurut nomor trigger pada tiket

pelanggan (auto increment)*;1{integer}10

notifikasi : *notifikasi trigger;1*{varchar}30

judul : *judul trigger;1*{varchar}25

kondisi : *kondisi trigger;1*{varchar}30

aksi : *aksi trigger;1*{varchar}30

pesan : *pesan yang akan dikirim;1*{200}

90

no_tiket : *nomor tiket pelanggan;1*{integer}10

info_tiket : *info tiket pelanggan;1*{varchar}20

tb_otomasi

{@id_otomasi + no_tiket + info_tiket + notifikasi + judul +

kondisi + aksi + pesan}ⁿ

@id_otomasi : *ID untuk mengurut nomor otomasi pada tiket

pelanggan (auto increment)*;1{integer}10

notifikasi : *notifikasi trigger;1*{varchar}30

judul : *judul trigger;1*{varchar}25

kondisi : *kondisi trigger;1*{varchar}30

aksi : *aksi trigger;1*{varchar}30

pesan : *pesan yang akan dikirim;1*{varchar}200

no_tiket : *nomor tiket pelanggan;1*{integer}10

info_tiket : *info tiket pelanggan;1*{varchar}20

tb_pj

{@id_pj + nama_pj + jenis_kelamin + tgl_lahir + tgl_masuk

+ alamat + kota + kode_pos + departemen + wilayah + email +

telp}ⁿ

@id_pj : *ID untuk mengurut penanggung jawab (auto


nama_pj : *nama penanggung jawab*;1{varchar}25

jenis_kelamin : *jenis kelamin penanggung jawab*;1{varchar}9

tgl_lahir : *tanggal lahir penanggung jawab*;1{date and time}

91

tgl_masuk : *tanggal masuk penanggung jawab*;1{date and time}

alamat : *alamat penanggung jawab*;1{50}

kota : *kota penanggung jawab*;1{25}

kode_pos : *kode pos penanggung jawab*;1{8}

departemen : *departemen penanggung jawab*;1{varchar}20

wilayah : *wilayah penanggung jawab*;1{varchar}25

email : *email;1*{varchar}15

telp :*telepon;1*{integer}15

tb_solusi

{@id_solusi + masalah + solusi }ⁿ

@id_solusi : *ID untuk mengurut solusi aduan pelanggan (auto


masalah : *masalah aduan pelanggan*;1{varchar}200

solusi : *solusi masalah aduan pelanggan*;1{varchar}200

tb_keljar

{@no_keljar + kelas_jaringan + keterangan }ⁿ

@no_keljar: *Nomor untuk mengurut kelas jaringan pelanggan

(auto increment)*;1{integer}5

kelas_jaringan : *kelas jaringan pelanggan*;1{varchar}10

keterangan: *keterangan kelas jaringan*;1{varchar}30

tb_kelas

{@no_kelas + kelas_pelanggan + keterangan }ⁿ

92

@no_kelas : *Nomor untuk mengurut kelas pelanggan (auto


kelas_pelanggan: *kelas pelanggan*;1{varchar}10

keterangan: *keterangan kelas pelanggan*;1{varchar}30

tb_departemen

{@id_departemen + departemen + keterangan }ⁿ

@id_departemen : *ID untuk mengurut departemen pegawai (auto


departemen : *departemen pegawai*;1{varchar}30

keterangan: *keterangan departemen pegawai*;1{varchar}30

4.6 Perancangan Database

Perancangan database dapat dilakukan dengan menggunakan

Entity Relationship Diagram (ERD).

4.6.1 Perancangan Entity Relationship Diagram (ERD)

Setelah menggunakan database dengan teknik

normalisasi, maka akan dihasilkan tabel yang telah

mencapai bentuk normal dan memiliki relasi satu

sama lain. Berikut rancangan ERD:

93

94

Gambar 4.17 Entity Relationship Diagram (ERD)

95

Penjelasan Gambar 4.17 ERD (Entity Relationship Diagram) adalah

sebagai berikut :

Gambar 4.17 menjelaskan ERD yang tampil ada beberapa entitas,

relasi, dan kardinalitas. Dilihat dari ERD, ada beberapa

entitas yang terdapat pada perancangan basis data, yaitu :

1. Pelanggan, attibutnya: id_pelanggan, nama_pelanggan,

alamat_pelanggan, kelas_pelanggan, email, telp

2. Kelas, atributnya : no_kelas, kelas_jaringan, keterangan

3. PJ, atributnya : id_pj, nama_pj, jenis_kelamin,

tgl_lahir, tgl_masuk, alamat, kota, kode_pos,

departemen, wilayah, email, telepon

4. Login, atributnya : username, password

5. Departemen, atributnya : id_departemen, departemen,

keterangan

6. Tiket, atributnya : no_tiket, info_tiket, stat_update,

tgl_mulai, tgl_selesai, durasi, masalah,no_jar,

nama_jaringan, kelas_jaringan, nama_pelanggan,

kelas_pelanggan, nama_pj, kelas_pj

7. Jaringan, atributnya : id_jaringan, nama_jaringan,

kelas_jaringan

8. Keljar, atributnya : no_keljar, kelas_jaringan,

keterangan

9. Solusi, atributnya : id_solusi, masalah, solusi

96

10. Trigger, atributnya : id_trigger, notifikasi,

judul, kondisi, aksi, pesan, no_tiket, info_tiket

11. Alert, atributnya : id_alert, aktivasi, no_tiket,

info_tiket

12. Otomasi, atributnya : id_otomasi, notiikasi, judul,

kondisi, aksi, pesan, no_tiket, info_tiket

Sedangkan, relasi dan kardinalitasnya pada ERD nya, adalah :

1. Relasi antara pelanggan dengan penanggung jawab

(helpdesk/CAR), yaitu one to one, satu pelanggan

mengubungi satu penanggung jawab (helpdesk/CAR).

2. Relasi antara penanggung jawab (helpdesk/CAR) dengan

login, yaitu one to one, satu penanggung

jawab(helpdesk/CAR) memiliki satu account untuk login

(username, password).


jaringan, yaitu one to many, satu helpdesk/CAR mengecek

banyak jaringan.

4. Relasi antara pelanggan dengan jaringan, yaitu one to

many, satu pelanggan dapat memasang banyak jaringan.

5. Relasi antara jaringan dengan kelas jaringan, yaitu

many to many, jaringan memiliki beberapa kelas

jaringan.

97

6. Relasi antara pelanggan dengan kelas, yaitu one to one,

satu pelanggan hanya memiliki satu kelas pelanggan.


tiket, yaitu one to one, satu penanggung jawab

(helpdesk/CAR) membuat satu tiket.

8. Relasi antara pelanggan dengan tiket, yaitu one to one,

satu pelanggan mendapat satu tiket.


departemen, yaitu one to one, satu penanggung jawab

(helpdesk/CAR) memiliki satu departemen.

10.Relasi antara tiket dengan solusi, yaitu one to one,

satu tiket menghasilkan satu solusi.

11.Relasi antara tiket dengan trigger, yaitu one to many,

satu tiket memiliki banyak trigger.

12.Relasi antara tiket dengan alert, yaitu one to one, satu

tiket hanya memiliki satu alert.

13.Relasi antara tiket dengan otomasi, yaitu one to many,

satu tiket memiliki banyak otomasi.

4.6.2 Normalisasi

Normalisasi berguna untuk mengidentifikasi

tabel kelompok atribut yang memiliki ketergantungan

tinggi antara satu atribut dengan atribut lainnya

(Ladjamudin, 2005).

1) Tabel Login98

a) Unnormalized Form (UNF)

Tabel 4.2 Tabel Login (UNF)

id_logi

n

username passwo

rd

b) First Normal Form (1 NF)

Tabel 4.3 Tabel Login (1 NF)

id_logi

n

username passwo

rd

Pada Tabel 4.3, sudah memenuhi kriteria 1NF

karena semua atributnya sudah bernilai atomic

dan tidak ada elemen data yang berulang.

c) Second Normal Form (2 NF)

Tabel 4.4 Tabel Login (2 NF)

id_logi

n

username

id_logi

n

password

99

id_login username

id_login password


karena nilai dari semua atribut yang bukan

primary key tergantung penuh pada primary key

(id_login).

2) Tabel Tiket


Tabel 4.5 Tabel Tiket (UNF)

no_ti

ket

info_t

iket

stat_up

date

tgl_mul

ai

tgl_sel

esai

dura

si

masala

h

no_ja

r

nama_jaring

an

.....

..

..

.

kelas_jarin

gan

nama_pelang

gan

kelas_pelang

gan

nama_p

j

kelas_

pj

b) First Normal Form (1NF)

Tabel 4.6 Tabel Tiket (1NF)

100

no_ti

ket

info_t

iket

stat_up

date

tgl_mul

ai

tgl_sel

esai

dura

si

masala

h

no_ja

r

nama_jaring

an

.....

..

..

.

kelas_jarin

gan

nama_pelang

gan

kelas_pelang

gan

nama_p

j

kelas_

pj




c) Second Normal Form (2NF)

Tabel 4.7 Tabel Tiket (2NF)

no_tik

et

info_ti

ket

stat_upd

ate

tgl_mul

ai

tgl_sel

esai

dura

si

masala

h

no_ja

r

nama_jaringa

n

...

..

..

..

.

no_kelja

r

kelas_jari

ngan

id_pelangga

n

nama_pelangg

an

no_kelas kelas_pelan

ggan

no_pj ....

.

..... nama_pj kelas_pj

101

no_tiket info_tiket + stat_update +

tgl_mulai + tgl_selesai + durasi + masalah

no_jar nama_jaringan

no_keljarkelas_jaringan

id_pelanggan nama_pelanggan

no_kelas kelas_pelanggan

no_pj nama_pj + kelas_pj




(no_tiket untuk tabel tiket; no_jar untuk

tabel jaringan; no_keljar untuk tabel kelas

jaringan; id_pelanggan untuk tabel pelanggan;

no_kelas untuk tabel kelas; dan no_pj untuk

tabel penanggung jawab (pj).

3) Tabel Pelanggan


Tabel 4.8 Tabel Pelanggan (UNF)

id_pelang

gan

nama_pelang

gan

alamat_pelan

ggan

kelas_pelangg

an

email telp

102


Tabel 4.9 Tabel Pelanggan (1NF)id_pelang

gan

nama_pelang

gan

alamat_pelan

ggan

kelas_pelangg

an

email telp





Tabel 4.10 Tabel Pelanggan (2NF)id_pelang

gan

nama_pelang

gan

alamat_pelan

ggan

no_kelas kelas_pelangg

an

email telp

id_pelanggan nama_pelanggan +

alamat_pelanggan + email + telp

no_kelas kelas_pelanggan




(id_pelanggan untuk tabel pelanggan; no_kelas

untuk tabel kelas.

103

4) Tabel Jaringan


Tabel 4.11 Tabel Jaringan (UNF)id_jaring

an

nama_jaring

an

kelas_jaring

an


Tabel 4.12 Tabel Jaringan (1NF)id_jaring

an

nama_jaring

an

kelas_jaring

an




c) Second Normal Form (2 NF)

Tabel 4.13 Tabel Jaringan (2 NF)id_jaring

an

nama_jaring

an

no_keljar kelas_jaring

an

id_jaringan nama_jaringan

no_keljar kelas_jaringan

104




(id_jaringan untuk tabel jaringan; no_keljar

untuk tabel kelas jaringan.

5) Tabel Trigger


Tabel 4.14 Tabel Trigger (UNF)id_trigg

er

notifika

si

judul kondisi aksi pesan no_tiket info_tike

t


Tabel 4.15 Tabel Trigger (1NF)id_trigg

er

notifika

si


t





Tabel 4.16 Tabel Trigger (2NF)

105

id_trigg

er

notifika

si


t

id_trigger notifikasi + judul + kondisi +

aksi + pesan

no_tiket info_tiket




(id_trigger untuk tabel trigger; no_tiket

untuk tabel tiket.

6) Tabel Alert


Tabel 4.17 Tabel Alert (UNF)

id_alert aktivasi no_tike

t

info_tik

et


Tabel 4.18 Tabel Alert (1NF)

106

id_alert aktivasi no_tike

t

info_tik

et





Tabel 4.19 Tabel Alert (2NF)id_alert aktivasi no_tike

t

info_tik

et

id_alert aktivasi

no_tiket info_tiket




(id_alert untuk tabel alert; no_tiket untuk

tabel tiket.

7) Tabel Otomasi


Tabel 4.20 Tabel Otomasi (UNF)

107

id_otoma

si

notifika

si


t


Tabel 4.21 Tabel Otomasi (1NF)id_otoma

si

notifika

si


t





Tabel 4.22 Tabel Otomasi (2NF)id_otoma

si

notifika

si


t

id_otomasi notifikasi + judul + kondisi +

aksi + pesan

no_tiket info_tiket


karena nilai dari semua atribut yang bukan108


(id_otomasi untuk tabel otomasi; no_tiket

untuk tabel tiket.

8) Tabel Penanggung Jawab (PJ)

a) Unnormalize Form (UNF)

Tabel 4.23 Tabel Penanggung Jawab (PJ)

(UNF)id_p

j

nama_p

j

jenis_kel

amin

tgl_la

hir

tgl_mas

uk

alam

at

kota kode_po

s

departe

men

.....

....

.

wilaya

h

email telepo

n



(1NF)id_p

j

nama_p

j

jenis_kel

amin

tgl_la

hir

tgl_mas

uk

alam

at

kota kode_po

s

departe

men

.....

....

.

wilaya

h

email telepo

n

109






(2NF)id_p

j

nama_p

j

jenis_kel

amin

tgl_la

hir

tgl_mas

uk

alam

at

kot

a

kode_po

s

id_departe

men

.....

....

.

departe

men

wilaya

h

email telepo

n

id_pj nama_pj + jenis_kelamin + tgl_lahir +

tgl_masuk + alamat + kota + kode_pos

id_departemen departemen + wilayah + email +

telepon




(id_pj untuk tabel penanggung jawab (pj);

id_departemen untuk tabel departemen.

110

9) Tabel Solusi


Tabel 4.26 Tabel Solusi (UNF)id_solus

i

masalah solusi


Tabel 4.27 Tabel Solusi (1NF)id_solus

i

masalah solusi




10) Tabel Keljar


Tabel 4.28 Tabel Keljar (UNF)no_kel

jar

kelas_jarin

gan

keterang

an


111

Tabel 4.29 Tabel Keljar (1NF)no_kel

jar

kelas_jarin

gan

keterang

an




11)Tabel Kelas Pelanggan

c) Unnormalize Form (UNF)

Tabel 4.30 Tabel Kelas (UNF)no_kel

as

kelas_pelan

ggan

keterang

an

d) First Normal Form (1NF)

Tabel 4.31 Tabel Kelas (1NF)no_kel

as

kelas_pelan

ggan

keterang

an




112

12) Tabel Departemen


Tabel 4.32 Tabel Departemen (UNF)id_departem

en

departemen keterangan


Tabel 4.33 Tabel Departemen (1NF)id_departem

en

departemen keterangan




4.6.3 Struktur Database

1) Tabel Login

Nama File : login.sql

Fungsi : Menyimpan data login

Primary : id_login

No Nama Field Tipe data Size Keterangan

113

1. id_login integer 10 ID Login Pengguna

2. username varchar 10 Username Pengguna

3. password varchar 8 Password Pengguna

2) Tabel Tiket

Nama File : tiket.sql

Fungsi : Menyimpan tiket aduan pelanggan

Primary : no_tiket


1. no_tiket integer 10 Nomor Tiket Aduan Pelanggan

2. info_tiket varchar 20 Informasi Tiket Pelanggan

3. stat_update varchar 20 Status UpdateTiket Pelanggan

4. tgl_mulai date and

time

Tanggal Mulai Penanganan

5. tgl_selesai date and

time

Tanggal Selesai Penanganan

6. durasi integer 10 Durasi Penanganan Aduan

7. masalah varchar 200 Masalah Aduan

114

8. no_jar integer 10 Nomor Jaringan Pelanggan

9. nama_jar varchar 30 Nama Jaringan Pelanggan

10.kelas_jarin

gan

varchar 10 Kelas Jaringan Pelanggan

11.nama_pelang

gan

varchar 25 Nama Pelanggan

12.kelas_pelan

ggan


13.nama_pj varchar 20 Nama Penanggung Jawab

(Helpdesk/CAR)

14.kelas_pj varchar 10 Kelas Penanggung Jawab

Pelanggan

3) Tabel Pelanggan

Nama File : pelanggan.sql

Fungsi : Menyimpan data pelanggan

Primary : id_pelanggan


1. id_pelanggan integer 10 ID Pelanggan Perusahaan

115

2. nama_pelangg

an

varchar 25 Nama Pelanggan Perusahaan

3. alamat_pelan

ggan

varchar 50 Alamat Pelanggan Perusahaan

4. kelas_pelang

gan

varchar 10 Kelas Pelanggan

5. email varchar 25 Email Pelanggan

6. telp integer 15 Nomor Telepon Pelanggan

4) Tabel Jaringan

Nama File : jaringan.sql

Fungsi : Menyimpan data jaringan pelanggan

Primary : id_jaringan


4. id_jaringan integer 10 ID Pelanggan Perusahaan

5. nama_jaringa

n

varchar 20 Nama Pelanggan Perusahaan

6. kelas_jaring

an


116

5) Tabel Trigger

Nama File : trigger.sql

Fungsi : Menyimpan data trigger

Primary : id_trigger


1. id_trigger integer 10 ID Trigger

2. notifikasi varchar 30 Notifikasi Trigger

3. judul varchar 25 Judul Trigger

4. kondisi varchar 30 Kondisi Trigger

5. aksi varchar 30 Aksi Trigger

6. pesan vacrhar 200 Pesan Yang Akan Dikirimkan Ke Email

7. no_tiket integer 10 Nomor Tiket Pelanggan


6) Tabel Alert

Nama File : alert.sql

Fungsi : Menyimpan data alert

Primary : id_alert

117


1. id_alert integer 10 ID Pelanggan Perusahaan

2. aktivasi varchar 10 Jenis Jaringan Pelanggan

3. no_tiket integer 10 Nama Pelanggan Perusahaan


7) Tabel Otomasi

Nama File : otomasi.sql

Fungsi : Menyimpan data otomasi

Primary : id_otomasi


1. id_otomasi integer 10 ID Otomasi

2. notifikasi varchar 30 Notifikasi Trigger

3. judul varchar 25 Judul Trigger

4. kondisi varchar 30 Kondisi Trigger

5. aksi varchar 30 Aksi Trigger

6. pesan vacrhar 200 Pesan Yang Akan Dikirimkan Ke Email

7. no_tiket integer 10 Nomor Tiket Pelanggan

118


8) Tabel Penanggung Jawab (PJ)

Nama File : pj.sql

Fungsi : Menyimpan data penanggung jawab

Primary : id_pj


1. id_pj integer 10 ID Pelanggan Perusahaan

2. nama_pj varchar 25 Nama Penanggung Jawab

3. jenis_kelami

n

varchar 9 Jenis Kelamin Penanggung Jawab

4. tgl_lahir date time Tanggal Lahir Penanggung Jawab

5. tgl_masuk date time Tanggal Masuk PJ

6. alamat varchar 50 Alamat PJ

7. kota varchar 25 Kota PJ

8. kode_pos integer 8 Kode Pos PJ

9. departemen varchar 20 Departemen PJ

119

10.wilayah varchar 25 Wilayah PJ

11.email varchar 15 Email Penanggung Jawab

12.telepon integer 15 Telepon Penanggung Jawab

9) Tabel Solusi

Nama File : solusi.sql

Fungsi : Menyimpan data solusi masalah

Primary : id_solusi


1. id_solusi integer 10 ID Solusi Masalah

2. masalah varchar 200 Detail Masalah Pelanggan

3. solusi varchar 200 Detail Solusi Masalah Pelanggan

10)Tabel Kelas Jaringan

Nama File : keljar.sql

Fungsi : Menyimpan data kelas jaringan

Primary : no_keljar


120

1. no_keljar integer 5 Nomor Kelas Jaringan

2. kelas_jaring

an

varchar 10 Kelas Jaringan

3. keterangan varchar 30 Keterangan Kelas Jaringan

11)Tabel Kelas

Nama File : kelas.sql

Fungsi : Menyimpan data kelas pelanggan

Primary : no_kelas


1. no_kelas integer 5 Nomor Kelas Pelanggan

2. kelas_pelang

gan

varchar 10 Kelas Pelanggan

3. keterangan varchar 30 Keterangan Kelas Pelanggan

12)Tabel Departemen

Nama File : departemen.sql

Fungsi : Menyimpan data departemen

Primary : id_departemen

121


1. id_departeme

n

integer 5 ID Departemen Pegawai

2. departemen varchar 30 Departemen Pegawai

3. keterangan varchar 30 Keterangan Departemen Pegawai

4.7 Perancangan Tampilan Aplikasi

4.7.1 Sistem Usulan Trigger (Pemicu)

Trigger (pemicu) adalah aturan yang akan

mengeksekusi perintah secara otomatis sebagai

akibat sampingan dari proses modifikasi

(insert/update/delete) dalam database. Pada sistem

usulan untuk aplikasi helpdesk, trigger dijalankan

setelah tiket dibuat atau di update. Contohnya,

sebuah trigger dapat digunakan untuk mengirimkan

notifikasi secara otomatis ke email pelanggan

ketika tiket dibuka (open ticket). Contoh lainnya

adalah sistem dapat secara otomatis mengirimkan

notifikasi email kepada pelanggan ketika tiket

telah terpecahkan (solved) dan tiket ditutup (close

ticket) oleh helpdesk/CAR. Hanya petugas helpdesk yang

dapat membuat dan mengatur trigger. 122

4.7.1.1 Perancangan Tampilan Usulan Sistem Trigger

(Pemicu)

Gambar 4.18 Tampilan Sistem Usulan Trigger (Pemicu) Untuk

Mengirim Notifikasi Email

Penjelasan Masing-Masing Fungsi Pada Halaman Pengaturan Trigger

(Pemicu):

1. Kolom sorted by position (urut berdasarkan posisi) berfungsi

untuk menampilkan daftar tiket sesuai posisi nomor urut

tiket.

2. Add trigger (menambah pemicu) berfungsi untuk menambah

trigger pada tiket yang akan dikirimkan notifikasi melalui

email.

123

Gambar 4.19 Pengaturan Trigger Pada Tiket

Gambar diatas menampilkan halaman pengaturan trigger untuk

mengaktifkan notifikasi “notify requester of recieved request”.

Jadi untuk setiap aduan dari pelanggan yang terkait

dengan gangguan jaringan akan dibuatkan tiket oleh

helpdesk/CAR dan disimpan ke dalam log gangguan. Setelah

memperoleh nomor tiket kemudian helpdesk/CAR membuat

trigger dan mengatur ketentuan trigger yg akan dikirimkan

kepada pelanggan. Trigger ini terhubung dengan database

tiket, sehingga setiap ada penambahan tiket baru ataupun

tutup tiket (close ticket), maka secara otomatis sistem akan

mengirimkan email yang memberitahu ke pelanggan bahwa

tiket telah diterima oleh helpdesk/ telah menjadi tiket

ataupun memberitahukan bahwa tiket telah ditutup (closed

124

ticket). Berikut ini merupakan penjelasan masing-masing

fungsi pada halaman penambahan trigger:

1) Trigger Title (judul pemicu) berfungsi untuk

membuat judul trigger pada notifikasi yang akan

dikirimkan ke pelanggan, misalnya helpdesk/CAR

akan membuat notifikasi kepada pelanggan bahwa

permintaan penanganan gangguan telah diterima

dan tiket telah dibuat, maka dapat diberi

judul notifikasi penerimaan permohonan

penanganan aduan.

2) Meet all of the following conditions (memenuhi semua

kondisi berikut) yang berarti helpdesk/CAR

mengetahui bahwa kondisi pada tiket semuanya

benar. Jika ada kondisi gagal (tidak benar),

trigger tidak akan bertindak pada tiket. Trigger

berisi kondisi dan aksi, maksudnya adalah

helpdesk/CAR dapat mengkombinasikkan tiket-

tiket ini untuk menciptakan “ if and then” - jika

dan kemudian (jika tiket berisi kondisi yang

benar kemudian aksi membuat update yang

diinginkan untuk tiket dan membuat notifikasi

ke pelanggan).

3) Pernyataan Kondisi

Pernyataan kondisi dapat dilogika kan sebagai

if statement (jika).

125

Tabel 4.35 Kondisi Otomatis

Kondisi PenjelasanStatus Status tiket aduan diantaranya adalah

New (Baru) = Tiket yang baru dibuat.

Open (Buka) = Tiket telah ditetapkan kepada

seorang yang bertanggung jawab menangani

aduan pelanggan (Helpdesk/CAR).

Pending (Tunda) = Tiket mengalami penundaan

pengerjaan, misalnya karena lokasi pelanggan

sedang mengalami banjir atau listrik mati

sehingga proses pengerjaan masalah pada

gangguan mengalami penundaan.

Closed (Tutup) = Tiket telah dikunci dan tidak

dapat dibuka kembali ataupun di update. Type (Tipe) Tipe tiket diantaranya adalah

Incident (Insiden) = Mengindikasikan bahwa ada

lebih dari satu kejadian dengan masalah yang

sama.

Problem (masalah) = Masalah yang membutuhkan

penyelesaian.Priority (Prioritas) Ada empat nilai dari prioritas, yaitu Low,

Normal, High, and Urgent.Assignee (Penunjuk) Yang termasuk assignee (penunjuk) diantaranya :

Requester = pemohon tiket. Anda dapat memilih

126

opsi ini untuk mengembalikan tiket yang

dibuka dan kemudian ditugaskan ke petugas

yang sama, misalnya.

Assignee = Orang yang ditugaskan pada tiket.Requester (Pemohon) Yang termasuk requester (pemohon) adalah

Requester (Pemohon) adalah pemohon tiket.

Assignee (Penerima) adalah orang yang

bertanggung jawab pada tiket. Current User (Pengguna

saat ini)

Yang termasuk kategori pengguna saat ini adalah

Agent (agen) = anggota staf

End user = helpdesk/CARTicket Satisfaction

(Kepuasan tiket)

Tingkatan kepuasan pelanggan, diantaranya:

Unoffered (Belum diterima) = Survey belum

diterima oleh pelanggan

Offered (Diterima ) = Survey telah dikirim

Bad = Tiket telah diterima dengan nilai

negatif

Good = Tiket telah diterima dengan nilai

positifTicket is ( tiket

adalah)

Tiket dibuat atau di update

Tickt received at (Tiket

diterima di )

Gunakan kondisi ini untuk menentukan alamat email

dimana tiket diterima

4) Pernyataan Aksi Otomatis

127

Pernyataan aksi mendefinisikan apa yang akan

terjadi jika semua pernyataan kondis adalah

benar dan trigger (pemicu) dijalankan.

Pernyataan aksi dapat di logika kan sebagai

“then” statement ( kemudian). Jadi jika semua

kondisi adalah benar maka panggil pernyataan

aksi ini untuk update tiket dan mengirimkan

notifikasi.

Tabel 4.36 Aksi Otomatis

Aksi PenjelasanStatus Status tiket aduan memiliki beberapa kategori,

diantaranya adalah :

New (Baru) = Tiket yang baru dibuat.

Open (Buka) = Tiket telah ditetapkan kepada

seorang yang bertanggung jawab menangani

aduan pelanggan (Helpdesk/CAR).

Pending (Tunda) = Tiket mengalami penundaan

pengerjaan, misalnya karena lokasi pelanggan

sedang mengalami banjir atau listrik mati

sehingga proses pengerjaan masalah pada

gangguan mengalami penundaan.

Closed (Tutup) = Tiket telah dikunci dan

tidak dapat dibuka kembali ataupun di update.Type (Tipe) Tipe-tipe tiket diantaranya adalah

128

Incident (Insiden) = Mengindikasikan bahwa ada

lebih dari satu kejadian dengan masalah yang

sama.

Problem (masalah) = Masalah yang membutuhkan

penyelesaian.Priority (Prioritas) Ada empat nilai dari prioritas, yaitu Low,

Normal, High, and Urgent.Assignee (Penunjuk) Yang termasuk assignee (penunjuk) adalah

Requester (Pemohon) = Pemohon tiket. Anda

dapat memilih opsi ini untuk mengembalikan

tiket yang dibuka dan kemudian ditugaskan ke

petugas yang sama, misalnya.

Assignee (Penunjuk) = Orang yang ditugaskan

pada tiket.Ticket Satisfaction

(Kepuasan tiket)

Permintaan survei telah dikirim ke pelanggan.

Email User (Email

Pengguna)

Alamat email yang telah di registrasi dan akan

menerima email.

Anda dapat mengatur pengguna email ke salah satu

dari berikut :

Pelanggan = Orang yang mengajukan tiket

aduan

Penerima = Helpdesk/CAR yang ditugaskan untuk

tiket

Semua = Mencakup semua staf yang memiliki

129

hak akses terhadap tiket pelanggan

5) Meet any of the following condition (Memenuhi kondisi

apapun)

Setidaknya satu dari kondisi apapun (any

conditions) juga harus benar, Pada kondisi

apapun (any conditions), jika salah satu dari

kondisi benar, trigger akan berjalan. Kondisi

apapun (any conditions) bertindak seperti semua

kondisi (all condition).

6) Email Body (Bagian email) = Aksi mengatur ticket

properties dan mengirimkan notifikasi email,

seperti pada Gambar 4.20 dibawah ini

Gambar 4.20 Bagian Tubuh Email

130

Untuk mengirimkan isi email dapat menggunakan placeholder.

Placeholder berfungsi untuk membuat teks di dalam sebuah input

form. Teks tersebut akan disembunyikan ketika form telah diisi

atau kursor telah diklik fokus ke form tersebut. Placeholder

adalah referensi untuk tiket dan data pengguna yang diletakan

pada subjek dan teks pemberitahuan email. Tanpa placeholder

tidak mungkin untuk membuat pesan otomatis. Placeholder diisi

diantara kurung kurawal ganda. Ketika mengirim notifikasi

email, pengguna dapat melihat daftar placeholder dengan

mengklik view available placeholders (lihat placeholder yang

tersedia), contoh {{ticket.submitter.name}},

{{current_user.name}},dan lain sebagainya.

Setelah semua ketentuan yang terdapat pada halaman add trigger

(penambahan trigger) diisi, maka helpdesk/CAR dapat menekan

tombol create trigger (buat trigger/pemicu) untuk melihat apakah

kondisi dan aksi sesuai dengan ketentuan. Jika antara kondisi

dan aksi tidak sesuai maka trigger tidak akan berjalan, namun

jika sesuai maka trigger akan sukses berjalan. Berikut gambar

4.19 yang menampilkan bahwa proses create trigger pada tiket

telah berhasil.

131

Gambar 4.21 Trigger Berhasil Diperbaharui

3. Deactivate (Menonaktifkan) = Tidak mengaktifkan notifikasi

pengiriman untuk tiket. Misalnya, perusahaan tidak ingin

menampilan fungsi notify all agents of received request, notify assignee

of assignment, notify group of assignment, maka helpdesk/CAR dapat

melakukan deactivate (non aktivasi) fungsi tersebut.

Berikut Gambar 4.22 yang menampilkan fungsi deactivate

notifikasi.

132

Gambar 4.22 Deactivated Notifikasi

4. Clone (Kloning) = Menyalin trigger yang telah dibuat dan

dan dapat di modifikasi untuk tujuan tertentu.

5. Edit = Memodifikasi judul, kondisi, dan aksi yang

dibutuhkan. Proses edit sama dengan menambahkan trigger.

6. Notify requester of received ticket (Memberitahu pemohon, tiket

telah diterima) = Memberitahu pelanggan bahwa aduan

mereka telah diterima dan telah menjadi tiket.

7. Notify requester of comment update = Beritahu pelanggan bahwa

helpdesk/CAR menambahkan komentar pada tiket dan akan

diberitahukan melalui emai.

8. Notify requester of solved request = Ketika agen menyelesaikan

tiket, pelanggan akan diberitahu melalui email. Pesan

email mengundang pelanggan untuk meninjau kembali

133

keputusan tersebut dan menambahkan komentar dan membuka

kembali tiket jika diperlukan

9. Notify asignee of comment update = Memberitahu agen ditugaskan

saat komentar ditambahkan ke tiket. Komentar dapat

berupa swasta (ditambahkan oleh petugas) atau publik

(ditambahkan oleh pelanggan atau petugas).

10. Notify asignee of assignment = Memberitahu tugas masing-

masing petugas.

11. Notify asignee of reopened ticket = Memberitahu petugas yang

ditugaskan bahwa tiket dibuka kembali.

12. Notify group of assignment = Memberitahu tugas kepada

kelompok.

13. Notify all agents of received request = Memberitahu semua

petugas (helpdesk/CAR, teknisi, dan lain-lain) tanpa

dibatasi bahwa permintaan perbaikan telah diterima.

4.7.2 Sistem Usulan Alert

Alert berungsi sebagai pengingat (remainder) untuk

helpdesk/CAR yang bertanggung jawab dalam menangani aduan

pelanggan. Alert ini akan aktif ketika helpdesk/CAR telah

melakukan pengaturan sebelumnya. Pada aplikasi helpdesk

ISDS ini, alert dapat berjalan apabila setelah lebih dari

2 jam helpdesk/CAR tidak melakukan update informasi ke

pelanggan terkait penangaan gangguan. Fungsi alert ini

134

akan ditambahkan pada database tiket di log gangguan.

Berikut ini merupakan gambar tiket aduan pelanggan yang

terdapat pada log gangguan yang telah berjalan pada

aplikasi helpdesk.

Gambar 4.23 Tiket Aduan Gangguan Pelanggan

Dapat dilihat bahwa log gangguan di atas hanya

memberikan informasi berkaitan dengan data gangguan dari

pelanggan yang masuk berikut data mengenai pelanggan.

Namun pada tiket tersebut belum terdapat informasi

apakah tiket aduan tersebut sudah dilakukan update

penanganan aduan ke pelanggan atau belum. Oleh karna

itu, tiket ini harus memiliki field (kolom) baru yang

berfungsi sebagai tempat meletakan status update ke

pelanggan.

4.7.2.1 Perancangan Tampilan Usulan Sistem Aler

Akan ada penambahan kolom database bernama

status aduan. Status aduan akan diletakkan di

antara kolom durasi dan MTTR. Apabila CAR belum135

melakukan update ke pelanggan selama 2 jam maka

sistem akan menampilkan tulisan berikut ini “Belum

update Ke Pelanggan” dengan penambahan blink (kerlap

kerlip) sehingga akan lebih terlihat jelas oleh

bagian CAR bahwa progress penanganan aduan belum

disampaikan kepada pelanggan. Untuk mematikan alert

tersebut, maka helpdesk/CAR harus memasukan data

gangguan pada input box yang nantinya akan disimpan

pada log gangguan yang berisi kronologis gangguan

dan disertai dengan detail informasinya. Berikut

Gambar 4.24 yang merupakan sistem usulan yang

diajukan.

Gambar 4.24 Sistem Usulan Alert

4.7.3 Sistem Usulan Automation (Otomasi)

136

Otomasi sama dengan trigger (pemicu) karena keduanya

mendefinisikan kondisi dan aksi yang sama pada ticket

properties dan dapat mengirimkan notifikasi email ke

pelanggan dan staf pendukung. Yang membedakan diantara

keduanya adalah otomasi berjalan ketika waktu kegiatan

terjadi (dari satu jam sampai 30 hari) setelah properti

tiket di atur dan di update, maka akan secara langsung

mengirimkan notifikasi. Hanya staf yang bertanggung jawab

yang dapat membuat dan mengatur otomasi. Otomasi membantu

mengatur alur kerja dan mengukur kinerja karena otomasi

tersebut dapat dijadikan suatu peringatan ke helpdesk/CAR

bahwa masih ada tiket yang masih belum di update maupun di

tutup. Berikut ini adalah beberapa manfaat dari penggunaan

otomasi :

Memberitahukan kepada helpdesk/CAR terkait ketika masih

terdapat tiket yang belum terpecahkan untuk x jumlah

jam.

Memberitahukan kepada helpdesk/CAR terkait bahwa masih

ada tiket yang belum di update ke pelanggan setelah x

jumlah jam

Memberitahukan kepada staf terkait agar menutup tiket

(close ticket) dalam x jumlah jam setelah masalah

terpecahkan.

Otomasi menggunakan kondisi yang berbasis waktu untuk

mengupdate tiket. Sebagai contoh, helpdesk/CAR mengatur tiket

137

agar ditutup 4 jam setelah petugas menyelesaikan masalah.

Otomasi berjalan sekali pada jam-jam yang telah diatur dan

hanya untuk tiket yang diupdate kurang dari 31 hari. Otomasi

dapat diaktifasi sesuai kebutuhan.

4.7.3.1 Perancangan Tampilan Usulan Sistem Otomasi

Gambar 4.26 Halaman Otomasi

1. Add Automation (Menambah Otomasi)

PT Aplikanusa Lintasarta ingin menambahkan otomasi

dengan waktu tertentu pada setiap tiket aduan pelanggan

agar helpdesk/CAR tidak lupa untuk memperbarui status

tiket ke pelanggan. Ketentuan dari perusahaan adalah

jika gangguan telah ditemukan,maka helpdesk/CAR harus

melakukan proses update (pembaruan) penanganan aduan ke

pelanggan. Jika lebih dari 4 jam, helpdesk/CAR belum

melakukan update penangan aduan gangguan, maka secara138

otomatis tiket akan dikirimkan ke email heldesk/CAR yang

bertanggung jawab dalam melakukan update penanganan aduan

pelanggan.

Gambar 4.27 Membuat Otomasi update Tiket Pelanggan Untuk

Helpdesk/CAR

Gambar 4.27 merupakan contoh dari penggunaan otomasi update

tiket pelanggan untuk helpdesk/CAR. Pada kolom kondisi diisi

dengan “ jika status tiket pelanggan adalah solved

(terpecahkan)”, maka kolom aksi diisi dengan ” kemudian jam

sejak masalah dipecahkan adalah 4”, maka aksi akan

menampilkan pengiriman notifikasi ke email helpdesk/CAR.

Apabila kondisi dan aksi sesuai, maka tiket akan berhasil

dibuat. Berikut ini Gambar 4.28 yang menampilkan otomasi

update tiket pelanggan berhasil dibuat.

139

Gambar 4.28 Otomasi update Tiket Berhasil Dibuat dan Telah

Aktif

Kemudian perusahaan juga ingin menambahkan otomasi untuk

tutup tiket ( close ticket) dimana ketika penanganan aduan

gangguan telah terpecahkan, maka staf (heldesk/CAR) harus

segera melakukan penutupan tiket (close ticket) jika dalam waktu

lebih dari 4 jam tidak dilakukan penutupan tiket, maka

otomasi tiket ke helpdesk/CAR akan berjalan. Berikut ini

Gambar 4.29 yang menampilkan ketentuan tersebut.

140

Gambar 4.29 Otomasi Close ticket

Pada kolom kondisi diisi dengan ketentuan “jika status tiket

adalah closed (tutup)”, maka kolom aksi diisi dengan “kemudian

jam sejak dilakukan penutupan tiket adalah 4 jam”, maka aksi

akan menampilkan status closed(tiket ditutup) dan akan dikirim

ke email helpdesk/CAR. Setelah kondisi dan aksi sesuai, maka

otomasi akan berhasil dijalankan, namun jika tidak sesuai,

maka otomasi akan gagal dijalankan. Berikut ini gambar 4.27

yang menampilkan bahwa otomasi tutup tiket (close ticket) telah

berhasil dibuat.

141

Gambar 4.30 Otomasi Closed Ticket Berhasil Diaktifkan

142

Rancang Bangung Aplikasi Bank Soal

Documents