TA : Rancang Bangun Aplikasi Penjadwalan Kunjungan dan Monitoring Pelanggan Pada PT. Royal Inti Mandiri Abadi Berbasis Web.

RANCANG BANGUN APLIKASI PENJADWALAN KUNJUNGAN DAN

MONITORING PELANGGAN PADA PT. ROYAL INTI MANDIRI ABADI

BERBASIS WEB

TUGAS AKHIR

Program Studi S1 Sistem Informasi

Oleh:

Sapta Indra Permana 10.41010.0096

FAKULTAS TEKNOLOGI DAN INFORMATIKA

Halaman

ABSTRAK ... vii

KATA PENGANTAR...viii

DAFTAR ISI ... x

DAFTAR GAMBAR ... xv

DAFTAR TABEL ... xxi

BAB I PENDAHULUAN ...1

1.1Latar Belakang Masalah...1

1.2Perumusan Masalah ...3

1.3Pembatasan Masalah ...4

1.4Tujuan ...4

1.5Manfaat ...4

1.6Sistematika Penulisan ...4

BAB II LANDASAN TEORI ...7

2.1 Sistem...7

2.2 Aplikasi ...7

2.3 Penjadwalan ...8

2.3.1 Pengertian Penjadwalan ...8

2.3.2 Prinsip Penjadwalan ...9

2.3.3 Tujuan Penjadwalan ...11

2.4 Monitoring ...12

2.4.4 Prinsip-Prinsip Monitoring ...14

2.4.5 Manfaat Monitoring ...14

2.4.6 Aspek Monitoring ...15

2.4.7 Langkah-Langkah Dalam Monitoring ...15

2.4.5 Tipe Monitoring ...17

2.5 Bagan Alir Sistem ...17

2.6 Data Flow Diagram (DFD) ...19

2.7 Entitiy Relationship Diagram (ERD)...20

2.8 MySQL...25

2.9 Hypertext Preprocessor (PHP) ...25

2.10 HTML ...26

2.11 Siklus Hidup Pengembangan Sistem (SDLC) ...26

2.12 Testing ...28

2.12.1 White Box Testing ...29

2.12.2 Black Box Testing ...30

BAB III AN ALISIS DAN PERANCANGAN SISTEM ...31

3.1 Identifikasi Permasalahan ...32

3.2 Analisis...33

3.2.1 Analisis Kebutuhan Sistem ...33

3.2.2 User Requirement ...35

3.2.3 Functional Requirement...36

3.3.3 System Flow ...40

3.3.4 Diagram Jenjang ...55

3.3.5 Context Diagram ...55

3.3.6 DFD-Level 0 ...56

3.3.7 DFD Level 1-Proses Memelihara Data Master ...57

3.3.8 DFD Level 1-Proses Membuat Jadwal K unjungan ...58

3.3.9 DFD Level 1-Proses Melakukan Pelaporan...59

3.3.10 Conceptual Data Modeling ...59

3.3.11 Physical Data Modeling ...60

3.3.12 Struktur Basis Data dan Tabel ...61

3.3.13 Sitemap...66

3.3.14 Desain User Interface ...66

3.3.15 Rancangan Pengujian dan Evaluasi Sistem ...106

BAB IV IMPLEMENTASI DAN EVALUASI ...117

4.1 Kebutuhan Sistem ...117

4.1.1 Kebutuhan Server...117

4.1.2 Kebutuhan Perangkat Lunak ...118

4.1.3 Kebutuhan Perangkat keras...118

4.2 Pembuatan Sistem ...118

4.3 Implementasi Sistem ...119

4.3.1 Halaman Login ...119

4.3.5 Halaman Master Sales ...126

4.3.6 Halaman Master Pelanggan ...129

4.3.7 Halaman Master Masalah...132

4.3.8 Halaman Master Harapan ...135

4.3.9 Halaman Manajemen Jadwal Kunjungan ...137

4.3.10 Halaman History Jadwal K unjungan ...142

4.3.11 Halaman Hasil Kunjungan ...144

4.3.12 Halaman History Kunjungan ...146

4.3.13 Halaman Buat Laporan K unjungan ...149

4.3.14 Halaman History Laporan ...154

4.3.15 Halaman Monitoring Sales ...154

4.3.16 Halaman Monitoring Pelanggan ...155

4.4 Uji Coba dan Evaluasi Sistem...156

4.4.1 Hasil Uji Coba Halaman Login ...157

4.4.2 Hasil Uji Coba Data Pengguna ...157

4.4.3 Hasil Uji Coba Data Zona ...158

4.4.4 Hasil Uji Coba Data Sales...159

4.4.5 Hasil Uji Coba Data Pelanggan ...160

4.4.6 Hasil Uji Coba Data Masalah ...161

4.4.7 Hasil Uji Coba Data Harapan...161

4.4.8 Hasil Uji Coba Data Jadwal Kunjugan ...162

4.4.12 Evaluasi Kesesuaian Akhir Sistem ...166

BAB V PENUTUP...168

5.1 Kesimpulan ...168

5.2 Saran...168

DAFTAR PUSTAKA ...170

1.1 Latar Belakang Masalah

Dengan semakin pesatnya persaingan antar perusahaan maka semakin besar tantangan yang harus dihadapi oleh perusahaan untuk mengembangkan perusahaannya. Salah satu cara yang dapat dilakukan oleh perusahaan agar dapat mengembangkan perusahaan dengan baik adalah dengan cara meningkatkan penjualan dan menjaga hubungan baik dengan pelanggan. Karena pelanggan merupakan orang yang teramat penting yang harus dipuaskan (Nasution, 2005).

PT. Royal Inti Mandiri Abadi, atau disebut PT. RIMA, adalah perusahaan yang bergerak dalam bidang distribusi semen. PT. Royal Inti Mandiri Abadi adalah distributor utama Semen Tiga Roda wilayah Jawa Timur perwakilan dari PT Indocement Tunggal Prakarsa, Tbk selaku produsen Semen Tiga Roda.

Sebagai sebuah perusahaan yang bergerak dalam bidang distribusi semen PT. Royal Inti Mandiri Abadi mempunyai banyak cabang yang terdapat di provinsi Jawa Timur yang kemudian disebut sebagi zona. Jumlah zona dan jumlah pelanggan dapat dilihat pada tabel 1.1

Tabel 1.1 Data Zona dan Pelanggan Pada PT. Royal Inti Mandiri Abadi (Sumber: Customer Service PT.RIMA)

No Nama Zona Pelanggan

1 Surabaya 4071

2 Lamongan 255

3 Pasuruan 952

4 Probolinggo 870

5 Jember 573

6 Banyuwangi 698

TOTAL 7 8121

Dalam setiap zona terdapat sales yang bertugas untuk memasarkan produk Semen Tiga Roda. Selain memasarkan produk tersebut sales mempunyai tugas untuk mengumpulkan informasi dari toko bangunan atau pelanggan.

Pada PT. Royal Inti Mandiri Abadi sales mempunyai tugas untuk mengumpulkan informasi dari toko pelanggan seperti menanggapi keluhan dari toko terkait dengan produk yang dipasarkan, besarnya kapasitas gudang toko, harga kompetitor, promo program dari kompetitor dan lain sebagainya. Untuk memperoleh informasi tersebut sales dapat melakukan kunjungan sesuai dengan jadwal yang telah dibuat sebelumnya oleh divisi Customer Service. Dari hasil kunjungan tersebut sales wajib membuat laporan dengan format yang telah ditentukan untuk kemudian diberikan kepada Kepala Perwalian zona.

Dalam kunjungan tersebut terdapat beberapa masalah yang seringkali harus dihadapi oleh divisi Customer Service seperti :

1. Sales melakukan kunjungan di luar batas waktu yang telah ditentukan.

2. Laporan yang diberikan kepada divisi Customer Service tidak valid atau tidak sesuai dengan yang diharapkan.

3. Jadwal kunjungan yang dibuat seringkali tidak tersampaikan dengan baik di masing- masing zona.

4. PT. Royal Inti Mandiri Abadi tidak bisa memonitoring kinerja dari masing-masing zona karena pembuatan jadwal kunjungan dan laporan yang dihasilkan masih manual dengan menggunakan aplikasi excel.

Pengawasan/controlling sebagai salah satu fungsi manajemen tentu saja mempunyai peranan yang sangat penting dalam proses manajemen karena dengan

adanya pengawasan dapat diketahui apakah pelaksanaan pekerjaan sesuai dengan yang direncanakan atau tidak, sehingga apabila terjadi penyimpangan dari rencana semula akan cepat dapat ditanggulangi (Handayaningrat, 1996). Banyaknya jumlah pelanggan sangat berdampak positif bagi PT. Royal Inti Mandiri Abadi, akan tetapi jika tidak dilakukan pengawasan dengan benar maka akan terjadi penurunan jumlah pelanggan.

Banyaknya jumlah pelanggan yang harus ditangani oleh sales di PT. Royal Inti Mandiri Abadi berdampak pada seringnya terjadi kesalahan pada saat sebelum dan sesudah dilakukan penjadwalan kunjungan ke pelanggan karena proses masih dilakukan secara manual seperti pembuatan jadwal kunjungan yang masih menggunakan email dan hasil laporan disimpan dengan menggunakan aplikasi excel. Oleh karena itu dibutuhkan adanya suatu aplikasi yang dapat mengelola penjadwalan kunjungan, monitoring kinerja pelanggan, dan monitoring kinerja sales sehingga aktivitas kunjungan yang terdapat pada tiap-tiap zona dapat dimonitor dengan baik dan dapat menghasilkan laporan yang informatif.

1.2 Perumusan Masalah

Berdasarkan latar belakang masalah diatas, maka dapat dirumuskan permasalahan sebagai berikut :

1. Bagaimana membangun sebuah aplikasi penjadwalan kunjungan pelanggan sehingga memudahkan pengelolaan jadwal kunjungan itu sendiri?

2. Bagaimana membangun sebuah aplikasi monitoring kinerja pelanggan yang dapat menghasilkan laporan yang informatif?

3. Bagaimana membangun sebuah aplikasi monitoring kinerja sales yang dapat menghasilkan laporan yang informatif?

1.3 Pembatasan Masalah

Berdasarkan perumusan masalah di atas, adapun batasan masalah pada penelitian ini adalah sebagai berikut:

1. Perancangan sistem aplikasi penjadwalan kunjungan dan monitoring pelanggan ini mencakup proses penjadwalan mulai dari pembuatan jadwal pada zona hingga pembuatan laporan kunjungan serta monitoring aktivitas pelanggan dan sales.

2. Sistem aplikasi penjadwalan kunjungan dan monitoring pelanggan ini tidak dapat melakukan tracking kunjungan sales ke pelanggan.

1.4 Tujuan

Dengan melihat perumusan masalah diatas, maka tujuan yang hendak dicapai adalah menghasilkan rancang bangun aplikasi penjadwalan kunjungan dan monitoring pelanggan di PT. Royal Inti Mandiri Abadi.

1.5 Manfaat

Dengan adanya sistem ini maka diharapkan memiliki beberapa nilai manfaat penulisan, antara lain :

1. Memudahkan divisi customer service dalam pembuatan jadwal kunjungan sales 2. Membantu divisi customer service dalam monitoring kinerja sales.

1.6 Sistematika Penulisan

Didalam penyusunan laporan tugas akhir ini secara sistematis diatur dan disusun dalam lima bab, yang masing-masing terdiri dari beberapa sub bab. Adapun urutan dari bab pertama sampai bab terakhir adalah sebagai berikut:

Bab ini membahas tentang latar belakang masalah, perumusan masalah, batasan masalah, tujuan pembuatan sistem, manfaat bagi penggunanya, serta sistematika penulisan laporan.

Bab II : LANDASAN TEORI

Bab ini membahas mengenai berbagai macam teori yang mendukung dalam pembuatan rancang bangun Sistem Aplikasi penjadwalan kunjungan dan monitoring pelanggan (Studi Kasus PT. Royal Inti Mandiri Abadi)..

Bab III : ANALISIS DAN PERANCANGAN SISTEM

Bab ini membahas analisis dan perancangan sistem. Analisis berisi penjelasan dari timbulnya masalah atau identifikasi permasalahan beserta penyelesaiannya atau analisis permasalahan , sedangkan perancangan sistem berisi System Flow, HIPO, Data Flow Diagram, Entity Relationship Diagram, Struktur Database, dan Desain Input / Output.

Bab IV : EVALUASI DAN IMPLEMENTASI

Bab ini membahas tentang kebutuhan sistem, pembuatan program, langkah-langkah implementasi, penggunaan sistem dalam proses bisnis serta pengujian untuk mengetahui apakah sistem yang dibangun dapat menyelesaikan permasalahan yang dihadapi sesuai dengan yang diharapkan. Dalam implementasi ini juga berisi penjelasan Graphical User Interface (GUI) sistem yang telah dibuat. Sedangkan evaluasi sistem berisi validasi dan uji coba sistem agar terhindar dari error serta berjalan sesuai yang diharapkan.

Bab V : PENUTUP

Bab ini berisi kesimpulan dan saran. Saran yang dimaksud adalah saran terhadap kekurangan dari aplikasi yang ada kepada pihak lain yang ingin meneruskan topik TA ini. Tujuannya adalah agar pihak lain tersebut dapat menyempurnakan aplikasi sehingga bisa menjadi lebih baik dan berguna.

BAB II

LANDASAN TEORI

2.1 Sistem

Sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran yang tertentu. (Jogiyanto, 2005)

Pendekatan sistem yang merupakan jaringan kerja dari prosedur lebih menekankan urut-urutan operasi di dalam system (Richard F. Neuschel, 2005),” Prosedur adalah sutu urut-urutan operasi klerikal (tulis menulis), biasanya melibatkan beberapa orang didalam satu atau lebih departemen, yang diterapkan untuk menjamin penanganan yang seragam dari transaksi- transaksi bisnis yang

terjadi”.

Suatu sistem mempunyai tujuan (goal) atau sasaran (objektifitas). Tujuan biasanya dihubungkan dengan ruang lingkup yang lebih luas dan sasaran dalam ruang lingkup yang lebih sempit. Sasaran menentukan masukan dan keluaran yang dihasilkan. Sistem dikatakan berhasil jika mencapai suatu sasaran dan tujuan.

2.2 Aplikasi

Aplikasi adalah perangkat lunak yang ada pada komputer digunakan untuk melayani berbagai macam kebutuhan. Teknologi yang canggih dari perangkat keras akan berfungsi bila instruksi- instruksi tertentu telah diberikan kepadanya. Instruksi- instruksi tersebut disebut dengan perangkat lunak (Jogiyanto, 2005).

Definisi lain aplikasi adalah program yang dibuat oleh pemakai yang ditujukan untuk melakukan suatu tugas khusus. Program seperti ini biasa

dikelompokkan menjadi dua yaitu program aplikasi serbaguna dan program aplikasi spesifik.

Program aplikasi serbaguna adalah program aplikasi yang dapat digunakan oleh pemakai untuk melaksanakan hal- hal yang bersifat umum (misalnya untuk membuat dokumen atau untuk pengiriman surat secara elektronis) serta untuk mengotomasikan tugas-tugas individual yang bersifat berulang (misalnya untuk melakkan perhitungan yang bersifat rutin). Termasuk dalam kategori ini antara lain adalah DBMS sederhana, Web browser, surat elektronis, pengolah kata (word processor), dan lembar kerja (spreadsheet). Program aplikasi serbaguna seringkali disebut perangkat lunak pemakai akhir (end-user-software).

Program aplikasi spesifik adalah program yang ditujukan untuk menangani hal- hal yang sangat spesifik. Misalnya, program pada sistem POS (point-of-sale) dan ATM. Termasuk dalam kategori ini adalah program yang disebut sebagai paket aplikasi atau perangkat lunak paket (Kadir, 2014).

2.3 Penjadwalan

2.3.1 Pengertian Penjadwalan

Penjadwalalan (scheduling) dapat di definisikan sebagai pengalokasian sumber daya dalam waktu tertentu untuk melakukan serangkaian tugas (Baker, 1974). Menurut Morton (1993), penjadwalan adalah proses pengorganisasian, pemilihan, dan penentuan waktu penggunaan sumber-sumber untuk mengerjakan semua aktifitas yang diperlukan yang memenuhi kendala aktifitas dan sumber daya.

Penjadwalan merupakan suatu kegiatan penting dalam perusahaan. Dalam suatu lembaga pendidikan, penjadwalan dilakukan untuk mealokasikan ruang

kelas, peralatan mengajar, tenaga mengajar, staff administrasi dan lain sebagainya. Demikian pula kegiatan perhotelan, penjadwalan diperlukan dalam pengaturan kamar hotel, ruang seminar atau resepsi, menu makanan ataupun entertainer. Terlepas dari jenis perusahaan, setiap perusahaan perlu untuk melakukan penjadwalan sebaik mungkin agar memperoleh utilitas maksimum dari sumber daya produksi dan aset yang dimiliki.

Melaksanakan pekerjaan secara efektif dan efisien agar tujuan tercapai adalah yang dinginkan oleh semua manajemen perusahaan. O leh karena itu pemahaman konsep penjadwalan sa ngat penting, sehingga para pelaksana mengetahui kapan harus memulai suatu pekerjaan dan kapan waktu mengakhirinya.

Penjadwalan adalah proses yang sering kita temui sehari hari. Pengaturan sumber daya yang tersedia sangat terbatas untuk berbagai kegiatan yang membutuhkannya pada periode waktu tertentu ini adalah inti dari masalah penjadwalan. Besarnya ukuran ruang pencarian solusi untuk masalah penjadwalan membuat proses penyusunan jadwal sangat susah dilakukan secara manual.

Penjadwalan yang baik akan membuat penggunaan resource menjadi lebih efektif. O leh karena itu, suatu proses kegiatan harus dialokasikan dengan baik dan memenuhi batasan-batasan yang ada. Permasalahan utama yang menjadi kendala dalam melakukan proses penjad walan adalah data (resource dan batasan) yang banyak dan frekuensi perubahan yang tinggi pada data. Dengan permasalahan seperti ini, proses komputasi dibutuhkan untuk memudahkan prses penjadwalan. Agar batasan dalam bahasa manusia dapat dikomputasi dan memberikan hasil sesuai dengan yang diinginkan.

2.3.2 Prinsip Penjadwalan

Prinsip penjadwalan menurut Suryadi H.S (1994) dibagi menjadi 3. Yaitu jadwal tetap, jadwal flexible dan keterbatasan (konflik dan hambatan), berikut ini merupakan penjelasannya:

1. Jadwal Tetap

Jadwal tetap sama dengan jadwal kereta api, dimana setiap aktiftas selalu dijalankan atau terjadi dalam waktu yang sama pada hari yang sama. Jadwal tetap hanya dapat diterapkan apabila setiap pekerjaan menjadi bagian dari set routine. Namun selain memperhatikan pekerjaan yang produktif kita juga harus memperhatikan:

1. Pekerjaan khusus yang on-time (sekali dikerjakan)

2. Rerun (Perjalanan kembali) pekerjaan produksi karena terjadinya kesalahan atau kegagalan.

3. Pengembangan dan pemeliharaan sistem dan program.

4. Perawatan pekerjaan, seperti pengkopian pita, pengujian, dan sebagaianya. Untuk sebagian besar instalasi, jadwal tetap sangat terlibat dalam penyusunan atau penetapan waktu input serta output dan akan terbukti terlalu terbatas.

2. Jadwal Fleksibel

Kebanyakan instalasi memerlukan sistem penjadwalan yang fleksibel untuk penerimaan input dan penyampaian output sepanjang berbagai tahapan pemrosesan yang didasarkan pada:

1. Waktu yang bisa diterima 2. Waktu optimum

Dalam kegiatan normal, output bisa muncul atau didapat dalam waktu optimum jika input yang diterima dalam waktu deadline. Dimungkinkan pula, meskipun tidak dijamin, hasil yang diproduksi bisa didapat secara on time (tepat waktu) meskipun outputnya terlambat.

3. Konflik dan Hambatan (Keterbatasan)

Masalah penjadwalan menjadi konflik tetap antara pemenuhan kepada departemen pemakai dengan cara menghasilkan output secara tepat waktu dengan pencapaian keluaran yang maksimum dengan muatan kerja yang seimbang, atau dengan kata lain antara layanan maksimum dengan efektivitas biaya.

Di satu sisi, hambatan atau keterbatasan diakibatkan oleh keperluan aktifitas pemrosesan, dan di sisi lain oleh kemampuan pemakai untuk mengontrol waktu input dan volume.

2.3.3 Tujuan Penjadwalan

Kegunaan suatu pekerjaan perlu adanya penjadwalan yaitu:

1. Mengurangi timbunan pekerjaan yang terlalu banyak dan kepadatan pemrosesan.

2. Membuat efektif penggunaan sumber daya 3. Memenuhi keperluan pemakai.

Jadwal harus bersifat:

1. Fleksibel untuk dijadwal ulang apabila diperlukan 2. Berisi informasi yang memadai

Dengan memperhatikan kedua hal tersebut yaitu kegunaan serta sifat penjadwalan, maka tujuan penjadwalan dapat dicapai sehingga pekerjaan dapat diselesaikan secara tepat waktu.

2.4 Monitoring

2.4.1 Pengertian Monitoring

Monitoring adalah penilaian yang terus menerus terhadap fungsi kegiatan-kegiatan proyek di dalam konteks jadwal-jadwal pelaksanaan dan terhadap penggunaan input- input proyek oleh kelompok sasaran di dalam konteks harapan-harapan rancangan. Monitoring adalah kegiatan proyek yang integral, bagian penting dari praktek manajemem yang baik dan karena itu merupakan bagian yang integral dari manajemen sehari-hari (Casely & Kumar 1987).

Monitoring adalah kegiatan mengamati perkembangan pelaksanaan rencana suatu kegiatan, mengidentifikasi serta mengantisipasi permasalahan yang timbul dan atau akan timbul untuk dapat diambil tindakan sedini mungkin.

Monitoring adalah proses pengumpulan dan analisis informasi (berdasarkan indikator yang ditetapkan) secara sistematis da n kontinu tentang kegiatan program / proyek sehingga dapat dilakukan tindakan koreksi untuk penyempurnaan program / proyek itu selanjutnya (Harry Hikmat 2010).

Monitoring adalah proses rutin pengumpulan data dan pengukuran kemajuan atas objektif program. Memantau perubahan, yang focus pada proses dan keluaran. Monitoring melibatkan perhitungan atas apa yang kita lakukan. Monitoring melibatkan pengamatan atas kualitas dari layanan yang kita berikan 2.4.2 Tujuan Monitoring

1. Mengkaji apakah kegiatan-kegiatan yang dilaksanakan telah sesuai dengan rencana.

2. Mengidentifikasi masalah yang timbul agar langsung dapat diatasi

3. Melakukan penilaian apakah pola kerja dan manajemen yang digunakan sudah tepat untuk mencapai tujuan proyek.

4. Mengetahui kaitan antara kegiatan dengan tujuan untuk memperoleh ukuran kemajuan.

5. Menyesuaikan kegiatan dengan lingkungan yang berubah, tanpa menyimpang dari tujuan

2.4.3 Fungsi Monitoring

Terdapat 4 fungsi dalam monitoring, antara lain: 1. Ketaatan (compliance)

Monitoring menentukan apakah tindakan administrator, staf, dan semua yang terlibat mengikuti standar dan prosedur yang telah ditetapkan

2. Pemeriksaan (auditing)

Monitoring menetapkan apakah sumber dan layanan yang diperuntukkan bagi pihak tertentu bagi pihak tertentu (target) telah mencapai mereka.

3. Laporan (accounting)

Monitoring menghasilkan informasi yang membantu “menghitung” hasil perubahan sosial dan masyarakat sebagai akibat implementasi kebijaksanaan sesudah periode waktu tertentu

Monitoring menghasilkan informasi yang membantu menjelaskan bagaimana akibat kebijaksanaan dan mengapa antara perencanaan dan pelaksanaannya tidak cocok.

2.4.4 Prinsip-Prinsip Monitoring

Terdapat 7 prinsip-prinsip dalam monitoring, antara lain: 1. Monitoring harus dilakukan secara terus-menerus

2. Monitoring harus menjadi umpan terhadap perbaikan kegiatan program organisasi

3. Monitoring harus memberi manfaat baik terhadap organisasi maupun terhadap pengguna produk atau layanan.

4. Monitoring harus dapat memotifasi staf dan sumber daya lainnya untuk berprestasi

5. Monitoring harus berorientasi pada peraturan yang berlaku 6. Monitoring harus obyektif

7. Monitoring harus berorientasi pada tujuan program 2.4.5 Manfaat Monitoring

Manfaat monitoring bagi penanggung jawab:

1. Salah satu fungsi manajemen yaitu pengendalian atau supervisi. Sebagai bentuk pertanggungjawaban (akuntabilitas) kinerja.

2. Untuk meyakinkan pihak-pihak yang berkepentingan.

3. Membantu penentuan langkah-langkah yang berkaitan dengan kegiatan selanjutnya.

4. Sebagai dasar untuk melakukan monitoring dan evaluasi selanjutnya. Manfaat monitoring bagi pengelola:

1. Membantu untuk mempersiapkan laporan dalam waktu yang singkat

2. Mengetahui kekurangan-kekurangan yang perlu diperbaiki dan menjaga kinerja yang sudah baik.

3. Sebagai dasar (informasi) yang penting untuk melakukan evaluasi proyek 2.4.6 Aspek Monitoring

Terdapat 3 aspek monitoring, antara lain:

1. Aspek masukan (input) kegiatan antara lain mencakup: tenaga manusia, dana, bahan, peralatan, jam kerja, data, kebijakan, manajemen dan sebagaimya. Yang dibutuhkan untuk melaksanakan kegiatan kegiatan.

2. Aspek proses / aktivitas yaitu aspek dari kegiatan yang mencerminkan suatu proses kegiatan, seperti penelitian, pelatihan, proses produksi, pemberian bantuan dan sebagainya.

3. Aspek keluaran (output), yaitu aspek kegiatan yang mencakup hasil dari proses yang terutama berkaitan dengan kuantitas (jumlah).

2.4.7 Langkah-Langkah Dalam Monitoring

Terdapat 3 langkah-langkah dalam monitoring, antara lain: 1. Perencanaan

a) Merancang sistem monitoring yang spesifik: apa yang akan dimonitor, mengapa dan untuk siapa (user).

b) Menentukan scope monitoring: luasnya area (Rumah Sakit, puskesmas non TT)? Apakah bersifat klinis atau service? Siapa yang terlibat? Berapa lama monitoring akan dilakukan?

c) Memilih dan menentukan indikator menentukan batasan sasaran kelompok misalnya kelompok anak dibawah 2 tahun, 5 tahun atau antara 12-60 bulan

d) Menentukan sumber-sumber informasi, memilih metoda pengumpulan data, seperti metoda observasi, interview petugas, rapid survey untuk cakupan atau pengobatan di rumah (home treatment).

2. Implementasi

a) Memilih dan menentukan proses supervisi dan prosessingnya (kemana akan dikirim).

b) Tabulasi data dan analisa data: membandingkan temuan atau pencapaian aktual dengan perencanaan.

c) Temuan dalam monitoring: apakah ada penyimpangan, bila ada perlu diidentifikasi masalah penyebabnya.

d) Menggali penyebab dan mengambil tindakan perbaikan: menggali penyebab terjadinya masalah. Rencana monitoring perlu disusun jangka pendek untuk menjamin bahwa tindakan/prosedure dilaksanakan sesuai standar (rencana) serta memberi efek sesuai dengan harapan.

3. Menentukan kelanjutan monitoring

Kegiatan monitoring dirancang untuk memperoleh hasil kinerja sekarang atau jangka pendek bagi manajer atau user lainnya. Ketika program atau kegiatan rutin telah memberikan perubahan signifikan, maka kelangsungan pro gram kinerja memerlukan perhatian. Review secara periodik tetap diperlukan. Sistem informasi manajemen akan membantu manajer untuk mempertimbangkan kapan indikator

dan frekuensi monitoring dikurangi dan pada bagian mana perlu direncanakan lagi dan dilanjutkan.

2.4.8 Tipe Monitoring

Terdapat 2 tipe dalam monitoring, antara lain: 1. Monitoring Rutin

Kegiatan mengkompilasi informasi secara reguler berdasarkan sejumlah indikator kunci. Monitoring rutin dapat dipergunakan untuk mengidentifikasi penerapan program dengan atau tanpa perencanaan

2. Monitoring jangka Pendek

Dilakukan untuk jangka waktu tertentu dan biasanya diperuntukkan bagi aktifitas yang spesifik. Seringkali bila aktifitas atau proses-proses baru diterapkan, manajer ingin mengetahui, apakah sudah diterapkan sesuai rencana dan apakah sesuai dengan keluaran yang diinginkan.

2.5 Bagan Alir Sistem

Menurut Basuki (2003), Sistem flow adalah bagian yang menunjukkan arus pekerjaaan secara menyeluruh dari suatu sistem dimaana bagan ini menjelaskan urutan prosedur-prosedur yang ada dalam sistem dan biasanya dalam membuat sistem flow sebaiknya ditentukan pada fungsi yang melaksanakan atau bertanggung jawab terhadap sub-sub sistem. Bagan alir sistem menggunakan simbol sebagaimana terdapat pada tabel 2.1

Tabel 2.1 Simbol Bagan Aliran Sistem

No Simbol Nama Simbol Keterangan

1 Dokumen Simbol ini digunakan untuk

menunjukkan dokumen input dan output baik untuk proses

manual, mekanik, atau komputer.

2 Keputusan Simbol keputusan digunakan

untuk menggambarkan suatu kondisi yang mengharuskan sistem untuk memilih tindakan yang akan dilakukan

berdasarkan criteria tertentu. 3 Operasi manual Simbol ini digunakan untuk

menggambarkan proses yang terjadi secara manual yang tidak dapat dihilangkan dari sistem yang ada

4 Database Simbol ini digunakan untuk

menggambarkan media penyimpanan yang digunakan untuk menyimpan data pada sistem yang akan dibuat.

5 Proses Simbol proses digunakan untuk

menggambarkan proses yang terjadi dalam sistem yang akan dibuat

6 Input manual Simbol Proses yang digunakan

untuk menggambarkan proses yang terjadi dalam sistem yang akan dibuat.

2.6 Data Flow Diagram (DFD)

Menurut Kendall (2003: 241), Data Flow Diagram menggambarkan pandangan sejauh mungkin mengenai masukan, proses dan keluaran sistem, yang berhubungan dengan masukan, proses, dan keluaran dari model sistem yang dibahas. Serangkaian diagram aliran data berlapis juga bisa digunakan untuk merepresentasikan dan menganalisis prosedur-prosedur mendetail dalam sistem. Prosedur-prosedur tersebut yaitu konseptualisasi bagaimana data-data berpindah di dalam organisasi, proses-proses atau transformasi dimana data-data melalui, dan apa keluarannya. Jadi, melalui suatu teknik analisa data terstruktur yang disebut Data Flow Diagram, penganalisis sistem dapat merepresentasi proses-proses data di dalam organisasi. Menurut Kendall (2003: 265), dalam memetakan Data Flow Diagram, terdapat beberapa simbol yang digunakan antara lain:

1. External entity

Suatu external entity atau entitas merupakan orang, kelompok, departemen, atau sistem lain di luar sistem yang dibuat dapat menerima atau memberikan informasi atau data ke dalam sistem yang dibuat.

Gambar 2.1 Simbol External Entity 2. Data Flow

Data Flow atau aliran data disimbolkan dengan data tanda panah. Aliran data menunjukkan arus data atau aliran data yang menghubungkan dua proses atau entitas dengan proses.

Gambar 2.2 Simbol Data Flow 3. Process

Suatu proses dimana beberapa tindakan atau sekelompok tindakan dijalankan.

Gambar 2.3 Simbol Process 4. Data Store

Data store adalah simbol yang digunakan untuk melambangkan proses penyimpanan data.

Gambar 2.4 Simbol Data Store 2.7 Entity Relationship Diagram (ERD)

Entity relationship diagram (ERD) adalah gambaran pada sistem dimana di dalamnya terdapat hubungan antara entity beserta relasinya. Entity merupakan sesuatu yang ada dan terdefinisikan di dalam suatu organisasi, dapat abstrak dan nyata. Untuk setiap entity biasanya mempunyai attribute yang merupakan ciri entity tersebut. Attribute yaitu uraian dari entitas dimana mereka dihubungkan atau dapat dikatakan sebagai identifier atau descriptors dari entitas.

Entitas digolongkan menjadi independent atau dependent entity. Independent entity adalah apa yang tidak bersandar pada yang lain sebagai

Flow_1 Flow_1

identifikasi. Suatu dependent entity adalah apa yang bersandar pada yang lain sebagai identifikasi. Selain digolongkan menjadi independent atau dependent entity, terdapat jenis- jenis entitas khusus yaitu:

1. Associative Entity

Associative Entity (juga dikenal sebagai intersection entity) adalah entitas yang digunakan oleh rekanan dua entitas atau lebih untuk menyatukan suatu hubungan benyak - ke - banyak (Many to Many)

2. Subtypes Entity

Subtypes Entity digunakan di dalam hierarki generalisasi (generalization hierarchies) untuk menyajikan suatu subset kejadian dari entitas orangtua, yang disebut supertype, tetapi yang memiliki atribut atau hubungan yang berlaku hanya untuk subset.

Menurut Marlinda (2004: 28), atribute sebagai kolom di sebuah relasi mempunyai macam-macam jenis atribute yaitu :

a. Key Atribute

Atribute ini merupakan atribute yang unik dan tidak dimiliki oleh atribute lainnya, misalnya entity mahasiswa yang atribute-nya NIM.

Gambar 2.5 Key Attribute b. Particial key Atribute

Adalah Attribute yang tidak menjadi atau merupakan anggota dari Key Primer. Misalnya antara Cabang (toko) dan kode cabang.

Gambar 2.6 Particial Key Attribute c. Single Vallue Atribute

Atribute yang hanya memiliki satu nilai harga, misalnya entity mahasiswa dengan atribute-nya Umur (Tanggal lahir).

Gambar 2.7 Single Value Attribute d. Multi Vallue Atribute

Atribute yang banyak memiliki nilai harga, misalnya entity mahasiswa dengan atribute-nya pendidikan (SD, SMP, SMA).

Gambar 2.8 Multi Value Attribute e. Composite Atribute

Atribute yang memiliki dua harga, misalnya nama besar (nama kerja) dan nama kecil (nama asli)

Gambar 2.9 Composite Attribute f. Derived Attribute

Attribute yang yang nilai- nilainya diperoleh dari pengolahan atau dapat diturunkan dari table Attribute atau table lain yang berhubungan.

Gambar 2.10 Derived Attribute

Model Entity - Relationship (ER) mula- mula diusulkan oleh Peter pada tahun 1976 sebagai cara untuk mempersatukan pandangan basis data jaringan dan relasional. Langkah sederhana dari model ER adalah model data konseptual yang memandang dunia nyata sebagai kesatuan (entitias) dan hubungan (relationship).

Komponen dasar model merupakan diagram entity-relationship yang digunakan untuk menyajikan objek data secara visual. Entity Relationship Diagram mengilustrasikan struktur logis dari basis data yang mempunyai metodologi sebagai berikut:

Tabel 2.2 Ilustrasi Pembuatan ERD

Proses Keterangan

1. Menentukan Entitas Menentukan peran, kejadian, lokasi, hal nyata, dan konsep dimana pengguna akan menyimpan data.

2. Menentukan Relasi Tentukan hubungan antara pasangan entitas menggunakan matriks relasi. 3. Gambar ERD Sementara Entitas digambarkan dengan kotak dan

relasi dengan garis yang menghubungkan entitas.

4. Isi Kardinalitas Tentukan jumlah kejadian dari satu entitas untuk sebuah kejadian pada

entitas yang berhubungan.

5. Tentukan Kunci Utama Tentukan atribut yang mengidentifikasi satu dan hanya satu kejadian pada masing- masing entitas.

6. Gambar ERD berdasar Kunci

Hilangkan relasi Many-to-Many dan masukkan primary dan kunci tamu pada masing- masing entitas.

7. Menentukan Atribut Tuliskan field-field yang diperlukan oleh sistem.

8. Pemetaan Atribut Pasangkan atribut dengan satu entitas yang sesuai pada masing-masing atribut. 9. Gambar ERD dengan

Atribut

Aturlah ERD dari langkah 6 dengan menambahkan entitas atau relasi yang ditemukan pada langkah 8.

10. Periksa Hasil Apakah ERD sudah menggambar sistem yang akan dibangun.

Entity Relationship Diagram ini diperlukan agar dapat menggambarkan hubungan antar entity dengan jelas, dapat menggambarkan batasan jumlah entity dan partisipasi antar entity, mudah dimengerti pemakai dan mudah disajikan oleh perandang database. Untuk itu, entity relationship diagram dibagi menjadi dua jenis model, yaitu:

1. Conceptual Data model

Conceptual Data model (CDM) adalah merupakan model yang universal dan dapat menggambarkan semua struktur logic database (DBMS), dan tidak

bergantung dari software atau pertimbangan struktur data storage. Sebuah CDM dapat diubah langsung menjadi PDM.

2. Physical Data Model

Physical Data Model (PDM) adalah merupakan model ERD yang telah mengacu pada pemilihan software DBMS yang spesifik. Hal ini sering kali berbeda dikarenakan oleh struktur database yang bervariasi, mulai dari model schema, tipe data penyimpanan dan sebagainya.

2.8 MySQL

MySQL adalah sebuah perangkat lunak database (basis data) sistem terbuka yang sangat terkenal di kalangan pengembang sistem database dunia yang digunakan untuk berbagai aplikasi terutama untuk aplikasi berbasis web. MySQL mempunyai fungsi sebagai SQL (Structured Query Language) telah diperluas. MySQL umumnya digunakan bersama dengan PHP untuk membuat aplikasi yang dinamis dan powerful.

2.9 PHP (Hypertext Preprocessor)

Menurut Saputra (2011, p.1) PHP atau yang memiliki kepanjangan PHP Hypertext Preprocessor merupakan suatu bahasa pemrograman yang difungsikan untuk membangun suatu website dinamis. PHP menyatu dengan kode HTML, maksudnya adalah beda kondisi. HTML digunakan sebagai pembangun atau pondasi dari kerangka layout web, sedangkan PHP difungsikan sebagai prosesnya sehingga dengan adanya PHP tersebut, web akan sangat mudah di-maintenance. PHP berjalan pada sisi server sehingga PHP disebut juga sebagai bahasa server Side Scripting. Artinya bahwa dalam setiap menjalankan PHP, wajib adanya web server.

2.10 HTML (HyperText Markup Language)

HTML (HyperText Markup Language) adalah sebuah bahasa standar yang digunakan oleh browser internet untuk membuat halaman dan dokumen pada sebuah web yang kemudian dapat diakses dan dibaca layaknya sebuah artikel. HTML juga dapat digunakan sebagai penghubung antara file- file dalam situs atau dalam komputer dengan menggunakan localhost.

2.11 Siklus Hidup Pengembangan Sistem (SDLC)

Menurut pressman (2001), Model System Development Life Cycle (SDLC) ini biasa disebut juga dengan model waterfall atau disebut juga classic life cycle. Adapun pengertian dari SDLC ini adalah suatu pendekatan yang sistematis dan berurutan. Tahapan-tahapannya adalah Requirements (analisis sistem), Analysis (analisis kebutuhan sistem), Design (perancangan), Coding (implementasi), Testing (pengujian) dan Maintenance (perawatan).

Model eksplisit pertama dari proses pengembangan perangkat lunak, berasal dari proses-proses rekayasa yang lain. Model ini memungkinkan proses pengembangan lebih terlihat. Hal ini dikarenakan bentuknya yang bertingkat ke bawah dari satu fase ke fase lainnya, model ini dikenal dengan model waterfall, seperti pada gambar 2.11

Communication Project iniiation Requirement

gathering

Planning Estimating Scheduling Tracking

Modeling Analysis

Design

Deployment Delivery Support Feedback Construction

Code Test

Gambar 2.11 menunjukkan tahapan umum dari model proses waterfall. Model ini disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Akan tetapi, Pressman (2015) memecah model ini meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya.

Model ini merupakan model yang paling banyak dipakai dalam Software Engineering. Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap Communication, Planning, Modeling, Construction, dan Deployment.

Berikut ini adalah penjelasan dari tahap-tahap yang dilakukan di dalam Model Waterfall menurut Pressman (2015):

a. Communication

Langkah pertama diawali dengan komunikasi kepada konsumen/pengguna. Langkah awal ini merupakan langkah penting karena menyangkut pengumpulan informasi tentang kebutuhan konsumen/pengguna.

b. Planning

Setelah proses communication ini, kemudian menetapkan rencana untuk pengerjaan software yang meliputi tugas-tugas teknis yang akan dilakukan, risiko yang mungkin terjadi, sumber yang dibutuhkan, hasil yang akan dibuat, dan jadwal pengerjaan.

c. Modeling

Pada proses modeling ini menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding.

Proses ini berfokus pada rancangan struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural.

d. Construction

Construction merupakan proses membuat kode (code generation). Coding atau pengkodean merupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu software, artinya penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut untuk kemudian bisa diperbaiki.

e. Deployment

Tahapan ini bisa dikatakan final dalam pembuatan sebuah software atau sistem. Setelah melakukan analisis, desain dan pengkodean maka sistem yang sudah jadi akan digunakan user. Kemudian software yang telah dibuat harus dilakukan pemeliharaan secara berkala.

2.12 Testing

Menurut Romeo (2003), testing adalah proses pemantapan kepercayaan akan kinerja program atau sistem sebagaimana yang diharapkan. Testing Software adalah proses pengoperasikan software dalam suatu kondisi yang dikendalikan untuk verifikasi, mendeteksi error dan validasi. Verifikasi adalah pengecekkan atau pengetesan entitas-entitas, termasuk software, untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan. Validasi adalah melihat kebenaran sistem apakah proses yang telah

dituliskan sudah sesuai dengan apa yang dibutuhkan oleh pengguna. Deteksi error adalah testing yang berorentasi untuk membuat kesalahan secara intensif, untuk menentukan apakah suatu hal tersebut tidak terjadi. Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya. Adapun kegunaan dari test case ini, adalah sebagai berikut:

1. Untuk melakukan testing kesesuaian suatu komponen terhadap desain White Box Testing.

2. Untuk melakukan testing kesesuaian suatu komponen terhadap spesifikasi Black Box Testing.

2.12.1 White Box Testing

Menurut Romeo (2003), white box testing adalah suatu metode desain test case yang menggunakan struktur kendali dari desain prosedural. Seringkali white box testing diasosiasikan dengan pengukuran cakupan tes, yang mengukur persentase jalur-jalir dari tipe yang dipilih untuk dieksekusi oleh test cases. White box testing dapat menjamin semua struktur internal data dapat dites untuk memastikan validitasnya.

Cakupan pernyataan, cabang dan jalur adalah suatu teknik white box testing yang menggunakan alur logika dari program untuk membuat test cases alur logika adalah cara dimana suatu bagian dari program tertentu dieksekusi saat menjalankan program. Alur logika suatu program dapat direpresentasikan dengan flow graph.

Menurut Romeo (2003), Black box testing dilakukan tanpa adanya suatu pengetahuan tentang detail struktur internal dari sistem atau komponen yang dites, juga disebut sebagai functional testing. Black box testing bergfokus pada kebutuhan fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software.

Dengan adanya black box testing, perekayasa software dapat menggunakan kebutuhan fungsional pada suatu program. Black box testing dilakukan untuk melakukan pengecekan apakah sebuah software telah bebas dari error dan fungsi- fungsi yang diperlukan telah berjalan sesuai dengan yang diharapkan.

BAB III

ANALISIS DAN PERANCANGAN SISTEM

Pada bab ini akan dibahas tentang identifikasi masalah, analisis dan perancangan sistem, rancangan pengujian, dan evaluasi sistem dalam rancang bangun aplikasi penjadwalan kunjungan dan monitoring pelanggan berbasis web pada PT. Royal Inti Mandiri Abadi. Model pengembangan yang digunakan pada penelitian ini menggunakan teori Pressman (2015) yaitu dengan model waterfall dimana melalui tahapan-tahapan yang telah ditentukan, yaitu mengidentifikasi masalah, menganalisis dan merancang sistem, membangun sistem dan uji coba sistem. Secara garis besar digambarkan pada gambar 3.1.

3.1 Identifikasi Permasalahan

PT. Royal Inti Mandiri Abadi Abadi, atau disebut PT. RIMA, adalah perusahaan yang bergerak dalam bidang distribusi semen. PT. Royal Inti Mandiri Abadi adalah distributor utama Semen Tiga Roda wilayah Jawa Timur perwakilan dari PT Indocement Tunggal Prakarsa, Tbk selaku produsen Semen Tiga Roda.

Sebagai sebuah perusahaan yang bergerak dalam bidang distribusi semen PT. Royal Inti Mandiri Abadi mempunyai banyak cabang yang terdapat di provinsi Jawa Timur yang kemudian disebut sebagi zona.

Dalam setiap zona terdapat sales yang bertugas untuk memasarkan produk Semen Tiga Roda. Selain memasarkan produk tersebut sales mempunyai tugas untuk mengumpulkan informasi dari toko bangunan atau pelanggan.

Pada PT. Royal Inti Mandiri Abadi sales mempunyai tugas untuk mengumpulkan informasi dari toko pelanggan seperti menanggapi keluhan dari toko terkait dengan produk yang dipasarkan, besarnya kapasitas gudang toko, harga kompetitor, promo program dari kompetitor dan lain sebagainya. Untuk memperoleh informasi tersebut sales dapat melakukan kunjungan sesuai dengan jadwal yang telah dibuat sebelumnya oleh divisi Customer Service. Dari hasil kunjungan tersebut sales wajib membuat laporan dengan format yang telah ditentukan untuk kemudian diberikan kepada Kepala Perwalian atau Zona dan Kepala Perwalian akan mengevaluasi laporan kunjungan dan kemudian diberikan kepada divisi Customer Service.

Dalam kunjungan tersebut terdapat beberapa masalah yang seringkali harus dihadapi oleh divisi Customer Service seperti:

2. Laporan yang diberikan kepada divisi Customer Service tidak valid atau tidak sesuai dengan yang diharapkan.

3. Jadwal kunjungan yang dibuat seringkali tidak tersampaikan dengan baik di masing- masing zona.

4. PT. Royal Inti Mandiri Abadi tidak bisa memonitoring kinerja dari masing-masing zona karena pembuatan jadwal kunjungan dan laporan yang dihasilkan masih manual dengan menggunakan aplikasi excel.

Masalah lain muncul dengan banyaknya jumlah pelanggan yang harus ditangani oleh sales di PT. Royal Inti Mandiri Abadi yang berdampak pada seringnya terjadi kesalahan pada saat sebelum dan sesudah dilakukan penjadwalan kunjungan ke pelanggan karena proses masih dilakukan secara manual seperti pembuatan jadwal kunjungan yang masih menggunakan email dan hasil laporan disimpan dengan menggunakan aplikasi excel. Oleh karena itu dibutuhkan adanya suatu aplikasi yang dapat mengelola penjadwalan kunjungan, monitoring kinerja pelanggan, dan monitoring kinerja sales sehingga aktivitas kunjungan yang terdapat pada tiap-tiap zona dapat dimonitor dengan baik dan dapat menghasilkan laporan yang informatif. Sehingga dapat meningkatkan penjualan dan pelayanan kepada pelanggan PT. Royal Inti Mandiri Abadi itu sendiri.

3.2 Analisis

3.2.1 Analisis Kebutuhan Sistem

Untuk mengetahui permasalahan dalam sistem penjadwalan dan monitoring pelanggan yang terdapat pada PT. Royal Inti Mandiri Abadi (RIMA), diperlukan langkah-langkah dalam menganalisis kebutuhan aplikasi, yaitu:

Dalam menganalisa kebutuhan, dilakukanlah observasi terhadap pabrik. Observasi tersebut untuk mengamati proses yang dilakukan pihak divisi Customer Service dalam pembuatan jadwal kunjungan dan monitoring pelanggan. Langkah ini dilakukan untuk melihat dan mengidentifikasi sistem penjadwalan yang sedang digunakan pada saat ini. Apakah dalam sistem yang mereka gunakan pada saat ini sudah mencukupi atau masih memiliki kekurangan-kekurangan yang bisa menyebabkan masalah bagi divisi customer service dalam mengelola laporan kunjungan pelanggan. Dengan adanya observasi diharapkan mampu menyelesaikan masalah yang telah diuraikan di dalam latar belakang yang telah disusun dalam penelitian ini.

2. Wawancara

Metode wawancara bertujuan mengumpulkan informasi. Metode ini dilakukan dengan melakukan tanya jawab kepada Kepala bagian divisi Customer Service PT. Royal Inti Mandiri Abadi yang dalam penelitian ini dijadikan sebagai studi kasus pembuatan tugas akhir ini. Dalam tahap wawancara ini, peneliti menggali informasi mengenai seperti apa visi dan misi perusahaan, bagaimana proses bisnis dalam penjadwalan kunjungan dan monitoring pelanggan.

3. Studi Literatur dan Penentuan Solusi

Setelah selesai dalam melakukan pengamatan dan wawancara, maka langkah selanjutnya adalah studi literatur dan penentuan solusi. Pada tahapan ini, dilakukan studi literatur yang berguna untuk memperoleh informasi yang diperlukan dalam pembuatan rancang bangun aplikasi penjadwalan kunjungan dan monitoring pelanggan pada PT. Royal Inti Mandiri Abadi. Informasi yang didapat tidak hanya melalui buku saja, tetapi juga berupa jurnal ilmiah dan skripsi mahasiswa.

Informasi literature berupa proses penjadwalan dan proses monitoring pelanggan yang telah dijalankan di PT. Royal Inti Mandiri Abadi. Pengumpulan berkas ini bertujuan untuk mengidentifikasi masalah yang ada pada PT. Royal Inti Mandiri Abadi.

3.2.2 User Requirement

Guna mengetahui kebutuhan pengguna yang terkait beserta tugas-tugasnya dilakukan analisis kebutuhan pengguna (user requirement) pada tabel 3.1 di bawah yang telah disesuaikan yang terkait dengan aplikasi penjadwalan kunjungan dan monitoring pelanggan pada PT. Royal Inti Mandiri Abadi. Setelah dilakukan analisis kebutuhan pengguna selanjutnya akan dilakukan kebutuhan fungsional pada table 3.2. Berikut dicantumkan tugas-tugas pengguna berdasarkan observasi pada PT. Royal Inti Mandiri Abadi.

Table 3.1 Kebutuhan Informasi Pengguna

No. Pengguna Tugas User Requirement

1. Customer Service

1.1. Melakukan input data pelanggan

1.2. Melakukan input data sales

1.3. Melakukan input data masalah

1.4. Melakukan input data harapan

1.5. Melakukan input data Kepala Perwalian atau Zona

1.6. Membuat jadwal kunjungan pelanggan 1.7. Melakukan Evaluasi

laporan hasil

kunjungan pelanggan

1.1.Dapat melakukan input data pelanggan (T1)

1.2. Dapat melakukan input data sales (T2) 1.3. Dapat melakukan

input data masalah 1.4. Dapat melakukan

input data harapan 1.5.Dapat melakukan

input data Kepala Perwalian atau Zona (T3)

1.6.Mampu membuat jadwal kunjungan pelanggan (T4) 1.7.Dapat memberikan

No. Pengguna Tugas User Requirement

1.8. Melakukan

monitoring kinerja sales dan pelanggan

laporan kunjungan (T5)

1.8.Mampu memonitor kinerja sales dan pelanggan (T6)

2. Kepala

Perwalian atau Zona

2.1 Mendistribusikan jadwal kunjungan ke sales

2.2 Membuat laporan kunjungan

pelanggan

2.1 Dapat

mendistribusikan jadwal kunjungan pelanggan ke sales (T1)

2.2 Dapat membuat laporan kunjungan pelanggan (T2)

3.2.3 Functional Requirement

Table 3.2 Kebutuhan Fungsional

No. Pengguna User Requirement Functional Requirement

1. Customer Service

1.1.Dapat melakukan input data pelanggan (T1) 1.2. Dapat melakukan input data

sales (T2)

1.3.Dapat melakukan input data Kepala Perwalian atau Zona (T3)

1.4.Dapat melakukan input data Masalah (T4) 1.5.Dapat melakukan input

data harapan (T5) 1.6.Mampu membuat jadwal

kunjungan pelanggan (T4)

1.7.Dapat memberikan keputusan dari hasil laporan kunjungan (T5)

1.1.Fungsi menyimpan data pelanggan (U1) 1.2.Fungsi menyimpan

data sales (U2) 1.3.Fungsi menyimpan

data kepala

perwalian atau zona (U3)

1.4.Fungsi menyimpan data masalah (U4) 1.5.Fungsi menyimpan data harapan (U5) 1.6.Fungsi menyimpan

data jadwal kunjungan (U4) 1.7.Fungsi proses

pemberian keputusan dari hasil laporan

No. Pengguna User Requirement Functional Requirement

1.8.Mampu memonitor kinerja sales dan pelanggan (T6)

1.8.Fungsi proses monitoring kinerja sales dan pelanggan

2. Kepala Perwalian atau Zona

2.1 Dapat mendistribusikan jadwal kunjungan pelanggan ke sales (T1) 2.2 Dapat membuat laporan

kunjungan pelanggan (T2)

2.1 Fungsi cetak jadwal kunjungan (U1)

2.2 Fungsi proses pencatatan laporan kunjungan

pelanggan (U2)

3.3 Perancangan Sistem

Perancangan sistem ini bertujuan untuk mendefinisikan kebutuhan-kebutuhan fungsional yang menggambarkan aliran data dan alur sistem, dan sebagai tahap persiapan sebelum implementasi sistem. Perancangan sistem ini diharapkan dapat merancang dan mendesain sistem dengan baik, yang isinya meliputi langkah-langkah operasi dalam proses pengolahan data dan prosedur untuk mendukung operasi sistem.

Langkah-langkah operasi dalam perancangan dan pengembangan sistem ini adalah sebagai berikut:

a. Diagram Block b. Arsitektur Sistem c. System Flow d. Diagram Jenjang e. Data Flow Diagram

g. Physical Data Model (PDM) h. Struktur Basis Data dan Tabel i. Sitemap

j. Desain User Interface k. Desain Input/Output

l. Rancangan Pengujian dan Evaluasi Sistem 3.3.1 Diagram Block

Aplikasi sistem penjadwalan dan monitoring yang dibangun mampu untuk membuat jadwal kunjungan, membuat lapotan hasil kunjungan dan memonitoring kinerja sales dan pelanggan. Berikut merupakan bentuk diagram block aplikasi sistem penjadwalan dan monitoring yang akan dibuat sebagai berikut:

INPUT PROCCES OUTPUT

Data Sales

Data Zona

Data Pelanggan

Penjadwalan

Kunjungan ke Pelanggan

Monitoring Kinrja Pelanggan

Jadwal Kunjungan

Laporan Kunjungan

Grafik Kinerja Pelanggan

Data Laporan Kunjungan

Monitoring Kinerja Sales

Grafik Kinerja Sales

Gambar 3.2 Diagram Block 3.3.2 Arsitektur Sistem

milik penyedia layanan. Arsitektur sistem yang akan dibangun adalah seperti pada gambar 3.3

Tablet computer dekstop

laptop smartphone User

server internet

Gambar 3.3 Arsitektur Sistem

Dengan arsitektur sistem berbasis web, pengguna tidak perlu melakukan pengelolaan dan perawatan infrastruktur sistem karena hal tersebut merupakan tanggung jawab dari penyedia layanan. Pengguna cukup mendaftarkan diri melalui halaman web penyedia layanan maka sistem informasi penjadwalan kunjungan dan monitoring pelanggan bisa langsung digunakan. Untuk mengakses sistem, pengguna perlu menyediakan perangkat keras seperti komputer, laptop, tablet atau smartphone yang tersambung dengan koneksi internet.

Model pengguna utama dari sistem didefinisikan sesuai fungsi dan tanggung jawab dapat dilihat pda table 3.3

Tabel 3.3 Aktor Utama

Pengguna Fungsi

Customer Service Mengelola jadwal kunjungan Mengelola data Sales beserta hak aksesnya

Mengelola data master zona Mengelola data pelanggan Mengelola data masalah Mengelola data harapan

Melakukan Monitoring Pelanggan dan sales

Kepala Perwalian Membuat keputusan berdasarkan history pelanggan

3.3.3 System Flow

Berikut ini akan digambarkan Sistem Flow dari pengembangan aplikasi penjadalan kunjungan dan monitoring yang akan dibuat pada PT. Royal Inti Mandiri Abadi.

Tambah Master Pengguna

Customer Service

P

ha

se

Pilh Menu Tambah Pengguna

Menampilkan Form Tambah Pengguna

Form Tambah Pengguna

Menyimpan Data Pengguna Pengguna

Selesai Username

Pengguna Mulai

Password Pengguna

Nama Pengguna

Zona Pengguna

Simpan ? 1

Y

Data Tersimpan T Telp Pengguna

Email Pengguna

1

Zona

Gambar 3.4 Sistem Flow Tambah Master Pengguna

Pada sistem flow tambah master pengguna, alur dimulai dari customer service memilih menu tambah pengguna dan Sistem akan menampilkan form tambah pengguna setelah itu customer service mengisi inputan username pengguna, password, email, telefon, zona pengguna (diambil dari table zona yang ada didatabase). Data yang sudah diinputkan akan disimpan di dalam database table pengguna.

b. System Flow Update Master Pengguna

Update Master Pengguna

Customer Service

P

h

a

se

Pilih Pengguna

Form Update Pengguna

Mulai

Menampilkan Form Update Pengguna Pengguna

Ubah Password Pengguna

Ubah Nama Pengguna

Ubah Email Pengguna

1

1

Menyimpan Update Pengguna Pengguna

Selesai Simpan ?

Y

Data Tersimpan T

Ubah Telp Pengguna

Gambar 3.5 Sistem Flow Update Master Pengguna

Pada sistem flow update master pengguna, alur dimulai dari customer service memilih menu update pengguna (diambil dari table pengguna yang ada didatabase) dan Sistem akan menampilkan form update pengguna setelah itu customer service mengubah inputan nama pengguna, password, email, telefon.

c. System Flow Tambah Master Zona

Tambah Master Zona

Customer Service

P

h

a

se

Pilh Menu Tambah Zona

Menampilkan Form Tambah Zona

Form Tambah Zona

Menyimpan Data Zona Zona

Selesai Nama Zona

Mulai

Alamat Zona

Simpan ?

Y

Data Tersimpan T

Gambar 3.6 Sistem Flow Tambah Master Zona

Pada sistem flow tambah master zona, alur dimulai dari customer service memilih menu tambah zona dan Sistem akan menampilkan form tambah zona setelah itu customer service mengisi inputan nama zona, alamat zona. Data yang sudah diisi akan disimpan di dalam database table zona.

d. System Flow Update Master Zona

Update Master Zona

Customer Service

P

h

ase

Pilih Zona

Form Update Zona Mulai

Menampilkan Form Update Zona Zona

Ubah Nama Zona

Ubah Alamat Zona

Menyimpan Update Zona Zona

Selesai Simpan ?

Y

Data Tersimpan T

Gambar 3.7 Sistem Flow Update Master Zona

Pada sistem flow update master zona, alur dimulai dari customer service memilih menu update zona (diambil dari table zona yang ada didatabase) dan Sistem akan menampilkan form update zona setelah itu customer service mengubah inputan nama zona, alamat zona. Data yang sudah diupdate akan disimpan di dalam database table zona.

e. System Flow Tambah Master Pelanggan

Tambah Master Pelanggan

Customer Service

P

h

a

se

Pilh Menu Tambah Pelanggan

Menampilkan Form Tambah Pelanggan

Form Tambah Pelanggan

Menyimpan Data Pelanggan Pelanggan

Selesai Nama Toko

Mulai

Nama Pemilik

Simpan ?

Y

Data Tersimpan T

Alamat_pelanggan

Telp_pelanggan

1

1

Zona Zona

Gambar 3.8 Sistem Flow Tambah Master Pelanggan

Pada sistem flow tambah master pelanggan, alur dimulai dari customer service memilih menu tambah pelanggan dan Sistem akan menampilkan form tambah pelanggan setelah itu customer service mengisi inputan nama toko, nama pemilik, alamat, telefon, zona (diambil dari table zona yang ada didatabase). Data yang sudah diinputkan akan disimpan di dalam database table pelanggan.

f. System Flow Update Master Pelanggan

Update Master Pelanggan

Customer Service

P

h

a

se

Pilih Pelanggan

Form Update Pelanggan

Mulai

Menampilkan Form Update Pelanggan Pelanggan

Ubah Nama Toko

Ubah Nama Pemilik

Menyimpan Update Pelanggan Pelanggan

Selesai Simpan ?

Y

Data Tersimpan T

Ubah Alamat Pelanggan

Ubah Telp Pelanggan

1

1

Gambar 3.9 Sistem Flow Update Master Pelanggan

Pada sistem flow update master pelanggan, alur dimulai dari customer service memilih menu update pelanggan (diambil dari table pelanggan yang ada didatabase) dan Sistem akan menampilkan form update pelanggan setelah itu customer service mengubah inputan nama toko, nama pemilik, alamat, telefon. Data yang sudah diupdate akan disimpan di dalam database table pelanggan.

g. System Flow Tambah Master Sales

Tambah Master Sales

Customer Service

P

h

a

se

Pilh Menu Tambah Sales

Menampilkan Form Tambah Sales

Form Tambah Sales

Menyimpan Data Sales Sales

Selesai Nama Sales

Mulai

Email Sales

Aalamat Sales

Simpan ? 1

Y

Data Tersimpan T Zona Slaes

Telp Sales

1

Zona

Gambar 3.10 Sistem Flow Tambah Master Sales

Pada sistem flow tambah master sales, alur dimulai dari customer service memilih menu tambah sales dan Sistem akan menampilkan form tambah sales setelah itu customer service mengisi inputan nama sales, email, alamat, telefon, zona (diambil dari table zona yang ada didatabase. Data yang sudah diinputkan akan disimpan di dalam database table sales.

h. System Flow Update Master Sales

Update Master Sales

Customer Service

P

h

a

se

Pilh Menu Sales

Menampilkan Form Sales

Form Update Sales

Menyimpan Data Sales Sales

Selesai Ubah Nama Sales

Mulai

Ubah Email Sales

Ubah alamat Sales

Simpan ? 1

Y

Data Tersimpan T Ubah Zona Slaes

Ubah Telp Sales

1

Zona Sales

Ubah status

Gambar 3.11 Sistem Flow Update Master Sales

Pada sistem flow update master sales, alur dimulai dari customer service memilih menu update sales (diambil dari table sales yang ada didatabase) dan Sistem akan menampilkan form update sales setelah itu customer service mengubah inputan nama sales, email, alamat, telefon, zona (diambil dari table zona yang ada didatabase), status. Data yang sudah diupdate akan disimpan di dalam database

i. System Flow Tambah Master Masalah

Tambah Master Masalah

Customer Service

P

ha

se

Pilh Menu Tambah Masalah

Menampilkan Form

Tambah Masalah

Form Tambah Masalah

Menyimpan Data Masalah

Masalah

Selesai Nama Masalah

Mulai

Keterangan

Simpan ?

Y

Data Tersimpan T

Gambar 3.12 Sistem Flow Tambah Master Zona

Pada sistem flow tambah master Masalah, alur dimulai dari customer service memilih menu tambah masalah dan Sistem akan menampilkan form tambah masalah setelah itu customer service mengisi inputan nama masalah, keterangan. Data yang sudah diisi akan disimpan di dalam database table masalah.

j. System Flow Update Master Masalah

Update Master Masalah

Customer Service

P

ha

se

Pilh Menu Tambah Masalah

Menampilkan Form Update Masalah

Form Update Masalah

Menyimpan Update Data Masalah Masalah

Selesai Ubah Nama

Masalah Mulai

Ubah Keterangan

Simpan ?

Y

Data Tersimpan T Masalah

Gambar 3.13 Sistem Flow Update Master Masalah

Pada sistem flow update master masalah, alur dimulai dari customer service memilih menu update masalah (diambil dari table masalah yang ada didatabase) dan Sistem akan menampilkan form update masalah setelah itu customer service mengubah inputan nama masalah dan keterangan. Data yang sudah diupdate akan

k. System Flow Tambah Master Harapan

Tambah Master Harapan

Customer Service

P

ha

se

Pilh Menu Tambah Harapan

Menampilkan Form Tambah Harapan

Form Tambah Harapan

Menyimpan Data Harapan Harapan

Selesai Masalah

Mulai

Nama Harapan

Simpan ?

Y

Data Tersimpan T Masalah

Gambar 3.14 Sistem Flow Tambah Master Harapan

Pada sistem flow tambah master harapan, alur dimulai dari customer service memilih menu tambah harapan dan sistem akan menampilkan form tambah harapan setelah itu customer service mengisi inputan nama masalah (diambil dari table masalah yang ada didatabase) dan nama harapan. Data yang sudah diisi akan disimpan di dalam database table harapan.

l. System Flow Update Master Harapan

Update Master Harapan

Customer Service

P

ha

se

Pilh Menu Update Harapan

Menampilkan Form Update Harapan

Form Update Harapan

Menyimpan Update Data Harapan Harapan

Selesai Ubah Masalah

Mulai

Ubah Harapan

Simpan ?

Y

Data Tersimpan T Masalah

Harapan

Gambar 3.15 Sistem Flow Update Master Harapan

Pada sistem flow update master harapan, alur dimulai dari customer service memilih menu update harapan (diambil dari table harapan yang ada didatabase) dan sistem akan menampilkan form update harapan setelah itu customer service mengubah masalah dan harapan. Data yang sudah diupdate akan disimpan di dalam database table harapan.

m. System Flow Penjadwalan Kunjungan

Penjadwalan Kunjungan

Customer Service Zona Sales

P h a se Selesai Memilih Menu Penjadwalan Kunjungan Sales Memasukkan tanggal, lokasi, zona

Menu Penjadwalan Memasukkan pelanggan,subjek, dan sales Menyimpan Jadwal Zona Kunjungan Memilih Menu Penjadwalan Kunjungan Sales Menu Penjadwalan Mengecek Jadwal Kunjungan Sesuai Dengan Zona Menampilkan Jadwal Menampilkan Jadwal Mulai Mencetak Jadwal Jadwal Kegiatan Jadwal Kegiatan Sales Pelanggan Menampilkan Menu Penjadwalan

Gambar 3.16 Sistem Flow Penjadwalan Kunjungan

Pada sistem flow penjadwalan kunjungan, alur dimulai dari customer service memilih menu penjadwalan kunjungan (mengambil data dari table zona, sales, pelanggan yang ada didatabase) dan sistem akan menampilkan form penjadwalan setelah itu customer service mengisi inputan tanggal, lokasi, zona, pelanggan, agenda, sales. Data yang sudah diinputkan akan disimpan di dalam database table kunjungan.

Jadwal kunjungan yang sudah dibuat akan didistribusikan kepada kepala perwalian atau Zona. Kepala perwalian akan mengecek jadwal kunjungan dan mencetak dua rangkap jadwal kunjungan setelah itu jadwal kunjunan yang sudah dicetak akan dibagikan kepada sales yang ada di masing- masing zona.

n. System Flow Input dan Penyetujuan Hasil Kunjungan

Input dan Penyetujuan Hasil Kunjungan

Zona Customer Service

Pilh Menu Manajemen Laporan Menampilkan Form Input Laporan Form Input Laporan Menyimpan

Laporan Kunjungan Laporan

Selesai Tanggal Laporan Mulai Delivery Habbit Data Tersimpan Program Kompetitor Masalah Harapan Souvenir Harga Kompetitor Wallet Share 1 Pilh Menu Manajemen Laporan Menampilkan Daftar Laporan Kunjungan Daftar Laporan

Pilih Laporan Yang Akan Disetujui Disetujui ? Ubah Status Laporan (Setuju) Y Laporan Ubah Status Laporan (Tidak) T Laporan Laporan Kunjungan Sales

Gambar 3.17 Sistem Flow Input dan Penyetujuan Hasil Kunjungan Pada sistem flow input dan penyetujuan hasil kunjungan, alur dimulai dari Kepala Pewalian atau zona mendapatkan dokumen laporan kunjungan sales setelah itu kepala perwalian memilih menu manajemen laporan dan Sistem akan menampilkan form manajemen laporan setelah itu kepala perwalian mengisi inputan tanggal laporan, delivery habbit, wallet share, harga kompetitor, program kompetitor, masalah, harapan, souvenir. Data yang sudah diinputkan akan disimpan di dalam database table laporan.

Laporan kunjungan yang sudah dibuat akan didistribusikan kepada Customer Service. Customer Service akan mengecek daftar laporan kunjungan dan memilih laporan yang akan disetujui atau tidak disetujui. Hasil laporan akan disimpan kedalam tabel laporan yang ada di database

3.3.4 Diagram Jenjang

Diagram berjenjang merupakan alat perancangan sistem yang dapat menampilkan seluruh proses yang terdapat pada suatu aplikasi tertentu dengan jelas dan terstruktur. Secara garis besar diagram jenjang aplikasi penjadwalan kunjungan dan monitoring pelanggan dapat dilihat pada gambar 3.18.

0 APLIKASII PENJADWALAN KUNJUNGAN DAN MONITORING PELANGGAN 1 Memelihara Data Master 2 Membuat Jadwal Kunjungan 1.1 Memelihara Data Zona 1.2 Memelihara Data Pengguna 1.3 Memelihara Data Pelanggan 1.4 Memelihara Data Sales 2.1 Membuat Jadwal Baru 3 Laporan 3.1 Melaporkan Hasil Kunjungan Pelanggan 4 Monitoring Kinerja Sales dan

Pelanggan 1.5 Memelihara Data Masalah 1.6 Memelihara Data Harapan

Gambar 3.18 Diagram Jenjang Aplikasi Penjadwalan Kunjungan dan Monitoring Pelanggan

3.3.5 Context Diagram

Context diagram ini menggambarkan proses sistem secara umum pada sistem informasi penanganan keluhan pelanggan pada PT. Royal Inti Mandiri

Abadi. Dalam context diagram ini melibatkan 2 entity yaitu: Customer Service dan KP (Kepala Perwakilan) atau zona.

Data Harapan Data Mas alah Data Sales

Data Has il Kunjungan Data Jadwal Kunjungan fix

Data Jadwal Kunjungan

Data Has il Kunjungan Dari KP (Zona) Data Pelanggan

Data Pengguna Data Zona

0

Aplikas i Penjadwalan Kunjungan Sales

+

KP (Kepala Perwakilan) atau Zona

CS PT RIMA

Gambar 3.19 Context Diagram Aplikasi Penjadwalan Kunjungan dan Monitoring Pelanggan

3.3.6 DFD-Level 0

Gambaran sistem pada DFD level 0 merupakan hasil decompose dari context diagram, pada saat pembuatan DFD Level 0 terdapat pengembangan-pengembangan dari contex diagram, berikut DFD level 0 pada gambar 3.20

Data Harapan Data Masalah

Data Output Harapan Laporan

Data Output Masalah Laporan

Data Output Masalah Data Harapan Diinputkan

Data Output Masalah Data Masalah Diinputkan

Data Masalah

Data Harapan

Data Output Pelanggan Laporan Data Output Sales Kunjungan Data Output Sales Laporan

Data Output Sales

Data Sales Diinputkan Data Sales

Data Output Hasil Kunjungan

Data Hasil Kunjungan

Data Output Jadwal Kunjungan2

Data Output Pelanggan Laporan Data Output Zona Laporan

Data Output Pengguna Data Output Pelanggan Data Output Zona

Data Hasil Kunjungan Dari KP (Zona) Data Jadwal Kunjungan fix

Data Output Jadwal Kunjungan

Data Jadwal Kunjungan Diinputkan

Data Jadwal Kunjungan

Data Pelanggan Diinputkan

Data Pengguna Diinputkan Data Zona Diinputkan

Data Pelanggan Data Pengguna Data Zona

CS PT RIMA KP (Kepala Perwakilan) atau Zona 1 Memelihara Data Master + 2 Membuat Jadwal Kunjungan + 3 Melakukan Pelaporan + 1 Zona 2 Pengguna 3 Pelanggan 4 Kunjungan 7 Laporan 5 Sales 4 Melakukan Monitoring 9 Masalah 10 Harapan

Gambar 3.20 Diagram Level 0 Aplikasi Penjadwalan Kunjungan dan Monitoring 3.3.7 DFD Level 1-Proses Memelihara Data Master

Gambaran sistem pada DFD level 1 merupakan pengembangan dari DFD level 0 dalam proses memelihara data master. Berikut ini DFD Level 1 Proses memelihara data master pada gambar 3.21.

Data Mas alah Diinputkan

Data Harapan Diinputkan

Data Output Mas alah Data Output Mas alah Data Mas alah

Data Harapan

Data Output Zona3 Data Sales Diinputkan

Data Output Sales Data Sales

[Data Output Zona2] Data Output Pelanggan

Data Output Pengguna

Data Pengguna Diinputk an Data Pengguna

Data Output Zona Data Zona Diinputkan

Data Pelanggan Diinputkan

Data Pelanggan

Data Zona CS PT RIMA

1 Zona 2 Pengguna 3 Pelanggan 1 Memelihara Data Zona 2 Memelihara Data Pengguna 3 Memelihara Data Pelanggan 5 Sales 4 Memelihara Data Sales

9 Mas alah

10 Harapan 5 Memelihara Data Mas alah 6 Memelihara Data Harapan

Gambar 3.21 Diagram Level 1 Proses Memelihara Data Master

3.3.8 DFD Level 1-Proses Membuat Jadwal Kunjungan

Gambaran sistem pada DFD level 1, DFD level 1 merupakan pengembangan dari DFD Level 0 tentang proses membuat jadwal kunjungan, berikut DFD level 1 tentang proses membuat jadwal kunjungan dapat dilihat pada gambar 3.22

Data Jadwal Kunjungan Diinputkan

Data Output Jadwal Kunjungan

Data Jadwal Kunjungan Fix Data Jadwal Kunjungan

CS PT RIMA Kepala Perwakilan

atau Zona

4 Kunjungan

1

Membuat Jadwal Baru

Gambar 3.22 Diagram Level 1 Proses Membuat Jadwal Kunjungan

3.3.9 DFD Level 1-Proses Melakukan Pelaporan

Gambaran sistem pada DFD level 1, DFD level 1 merupakan pengembangan dari DFD Level 0 Proses melakukan pelaporan, berikut DFD level 1 tentang proses melakukan pelaporan dapat dilihat pada gambar 3.23.

Data Output Jadwal Kunjungan Laporan Data Output Pelanggan Laporan

Data Output Zona Laporan

Data Output Hasil Kunjungan

Data Hasil Kunjungan Diinputkan Data Hasil Kunjungan

Data Hasil Kunjungan Dari KP (Zona) 1

Melaporkan Hasil Kunjungan

CS PT RIMA Kepala Perwakilan atau Zona 5 Laporan 1 Zona 3 Pelanggan 4 Kunjungan

Gambar 3.23 Diagram Level 1 Proses Melakukan Pelaporan

3.3.10 Conceptual Data Model (CDM)

Conceptual Data Model (CDM) adalah gambaran secara keseluruhan struktur aplikasi. Dengan CDM kita bisa membangun desain awal sistem dan tidak perlu khawatir dengan detail implementasinya secara fisik. Dan melalui prosedur generation yang mudah, kita bisa melakukan generate CDM ke Physical Data Model (PDM).

Bentuk Conceptual Data Model dari Aplikasi penjadwalan kunjungan dan monitoring pelanggan pada PT. Royal Inti Mandiri Abadi adalah sebagai berikut

Gambar 3.24 Conceptual Data Model 3.3.11 Physical Data Modeling

Physical Data Model menggambarkan struktur data sebagaimana akan di implemtasikan oleh DBMS. Dalam PDM kita bisa mengoptimalkan database dengan memodifikasi tabel, kolom, index, refrential integrity, view, physical storage, trigger and stored procedure. Procedure database generation menerapkan hal itu dengan cara menyesuaikan dengan DBMS yang kita pilih.

Bentuk Physical data model dari generate conceptual data model untuk Aplikasi penjadwalan kunjungan dan monitoring pelanggan pada PT. Royal Inti Mandiri Abadi adalah sebagai berikut:

memiliki terdapat menjadwalkan dikunjungi berada2 berada membuat menghasilkan mempunyai melakukan mempunyai memiliki memilki level_pengguna id_level nama_level <pi> Integer Variable characters (30)

<M> Identifier_1 <pi> pengguna id_pengguna username password nama_pengguna email_pengguna telp_pengguna id_session <pi> Integer Variable characters (50) Variable characters (50) Variable characters (100) Variable characters (100) Variable characters (12) Variable characters (100)

<M> Identifier_1 <pi> zona id_zona nama_zona alamat_zona <pi> Integer Variable characters (50) Variable characters (150)

<M> Identifier_1 <pi> kunjungan id_kunjungan subjek_kunjungan lokasi_kunjungan tgl_pengajuan tgl_pelaksanaan tgl_laporan deskripsi_kunjungan status_kunjungan tgl_expired

<pi> Variable characters (5) Variable characters (100) Variable characters (150) Date & Time Date & Time Date & Time Text

Variable characters (12) Date & Time

<M> Identifier_1 <pi> laporan id_laporan tgl_hasil_laporan delivery_habbit wallet_share harga_kompetitor program_kompetitor souvenir status_laporan file_laporan

<pi> Variable characters (5) Date & Time Text Text Text Text Text Integer

Variable characters (200) <M> Identifier_1 <pi> pelanggan id_pelanggan nama_toko nama_pemilik alamat_pelanggan telp_pelanggan

<pi> Variable characters (5) Variable characters (50) Variable characters (100) Variable characters (150) Variable characters (12)

<M> Identifier_1 <pi> sales id_sales nama_sales email_sales alamat_sales telp_sales status_sales

<pi> Variable characters (5) Variable characters (100) Variable characters (100) Variable characters (150) Variable characters (25) Variable characters (12)

<M> Identifier_1 <pi> Masalah id_masalah nama_masalah keterangan <pi> Integer Variable characters (50) Variable characters (50)

<M> Identifier_1 <pi> Harapan id_harapan nama_harapan <pi> Integer

Variable characters (100) <M> Identifier_1 <pi>

Gambar 3.25 Physical Data Modeling 3.3.12 Struktur Basis Data dan Tabel

Struktur tabel digunakan dalam pembuatan sistem informasi penjadwalan kunjungan. Data-data dibawah ini akan menjelaskan satu per satu secara detil dari struktur tabel sistem.

a. Nama Tabel : Level Pengguna Primary Key : ID_Pengguna Foreign Key : -

Fungsi : Untuk menyimpan level pengguna yang akan mengakses ke sistem informasi manajemen keluhan.

FK_MEMILIKI FK_TERDAPAT FK_MENJADWALKAN FK_DIKUNJUNGI FK_BERADA2 FK_BERADA FK_MEMBUAT FK_MENGHASILKAN FK_MENGHASILKAN2 FK_MEMPUNYAI FK_MELAKUKAN FK_MEMPUNYAI2 FK_MEMILIKI2 FK_MEMILKI3 level_pengguna id_level nama_level int varchar(30) <pk> pengguna id_pengguna id_zona id_level username password nama_pengguna email_pengguna telp_pengguna id_session int int int varchar(50) varchar(50) varchar(100) varchar(100) varchar(12) varchar(100) <pk> <fk2> <fk1> zona id_zona nama_zona alamat_zona int varchar(50) varchar(150) <pk> kunjungan id_kunjungan id_pengguna id_sales id_pelanggan id_zona id_laporan subjek_kunjungan lokasi_kunjungan tgl_pengajuan tgl_pelaksanaan tgl_laporan deskripsi_kunjungan status_kunjungan tgl_expired varchar(5) int varchar(5) varchar(5) int varchar(5) varchar(100) varchar(150) datetime datetime datetime text varchar(12) datetime <pk> <fk1> <fk5> <fk2> <fk3> <fk4> laporan id_laporan id_pengguna id_harapan id_kunjungan id_masalah tgl_hasil_laporan delivery_habbit wallet_share harga_kompetitor program_kompetitor souvenir status_laporan file_laporan varchar(5) int int varchar(5) int datetime text text text text text int varchar(200) <pk> <fk1> <fk4> <fk2> <fk3> _pelanggan id_pelanggan id_zona nama_toko nama_pemilik alamat_pelanggan telp_pelanggan varchar(5) int varchar(50) varchar(100) varchar(150) varchar(12) <pk> <fk> sales id_sales id_zona nama_sales email_sales alamat_sales telp_sales status_sales varchar(5) int varchar(100) varchar(100) varchar(150) varchar(25) varchar(12) <pk> <fk> Masalah id_masalah nama_masalah keterangan int varchar(50) varchar(50) <pk> Harapan id_harapan id_masalah nama_harapan int int varchar(100) <pk> <fk>

167

Tabel 4.12 Hasil Evaluasi Kebutuhan Sistem

No Kebutuhan Hasil Bukti

1 Sistem dapat membuat dan mengelola jadwal kunjungan

Sukses. Sistem dapat melakukan penjadwalan kunjungan

Gambar 4.26, Gambar 4.27, Gambar 4.28, Gambar 4.29, Gambar 4.30, Gambar 4.31, Gambar 4.32, Gambar 4.33, Gambar 4.34, Gambar 4.35, Gambar 4.36, Gambar 4.37, Gambar 4.38, Gambar 4.39 2 Sistem dapat

membuat dan mengelola laporan hasil kunjungan

Sukses. Sistem dapat melakukan laporan hasil kunjungan

Gambar 4.41, Gambar 4.42, Gambar 4.43, Gambar 4.44, Gambar 4.45 2 Sistem dapat

melakukan monitoring kinerja sales dan pelanggan

Sukses. Sistem dapat melakukan proses

monitoring kinerja sales dan pelanggan.

Gambar 4.46 dan Gambar 4.47

1. BAB V PENUTUP

5.1 Kesimpulan

Berdasarkan tahap uji coba dan evaluasi terhadap Sistem Informasi Penjadwalan Kunjungan dan Monitoring pada PT. Royal Inti Mandiri Abadi, maka dapat ditarik beberapa kesimpulan sebagai berikut:

1. Dapat memberikan kemudahan dalam pengelolaan jadwal kunjungan sales mulai dari pembuatan jadwal kunjungan yang ditujukan kepada zona, hingga laporan hasil kunjungan dari zona yang bersangkutan.

2. Perusahaan dapat memantau kinerja dari masing-masing zona dalam melaksanakan kunjungan.

3. Dapat menyajikan laporan sesuai dengan keinginan dari Customer Service. 4. Dapat melakukan monitoring kinerja sales dan pelanggan

5.2 Saran

Apabila sistem informasi penjadwalan kunjungan sales ini digunakan pada perusahaan, maka disarankan beberapa hal sebagai berikut:

1. Diperlukan infrastruktur yang tepat untuk menjalankan sistem informasi penjadwalan kunjungan ini.

2. Pengguna sistem harus memenuhi segala prosedur yang dibutuhkan oleh sistem untuk mengimplementasikan sistem penjadwalan kunjungan ini dengan baik. 3. Jika nantinya sistem ini dikembangkan maka perlu ditambahkan fitur SMS

Gateway untuk mempermudah pemberitahuan kepada pihak zona

169

4. Penambahan fitur poin yang berupa reward dan punishment kepada zona untuk mengukur kinerja zona dalam melakukan kunjungan dan laporan yang dihasilkan pada tiap-tiap zona.