Abstrak
Manajemen armada merupakan kegiatan operasional perusahaan untuk layanan angkutan
orang ataupun barang, manajemen armada dilakukan untuk memperoleh informasi seperti
jarak yang ditempuh, tujuan yang dicapai, perbaikan serta pemeliharaan dan perencanaan
servis berkala. Penelitian sebelumnya telah menunjukkan bahwa banyak penelitian mengenai
manajemen armada tetapi penelitian tersebut dilakukan sebagian besar fokus pada salah satu
modul manajemen armada. Sistem manajemen armada ini menerapkan beberapa modul
seperti routing, shipment management dan vehicle management. Dalam studi ini, peneliti
mencoba untuk menerapkan sistem manajemen armada pada PT Kino yang memiliki 30
armada tetapi terdapat masalah yaitu perkiraan waktu pengiriman tidak dapat dipantau
dikarenakan perusahaan tidak mempunyai perencanaan rute yang tepat dalam setiap
pengiriman yang mengakibatkan optimalisasi rute dengan tata letak barang pada armada
tidak terstruktur, sehingga perusahaan tidak kunjung mempunyai perencanaan rute yang
optimal untuk pencapaian perusahaan. Selanjutnya perusahaan sulit memonitoring armada
saat proses pengiriman barang, hal ini dikarenakan proses yang berjalan masih dilakukan
secara minimalis yang mengakibatkan adanya data laporan berbeda antara pelanggan dan
bagian pengiriman. Setelah melakukan pembangunan sistem yang dibutuhkan, tes penerimaan
pengguna dilakukan dengan hasil sebesar 83.95% dari 41 kasus uji yg dilakukan oleh 6 aktor.
Untuk pengembangan sistem manajemen armada ini maka disarankan agar dapat melakukan
live tracking menggunakan Maps.
88 e-ISSN 2685-5518
INFORMATIKA DAN RPL, Vol. 2, No. 2, September 2020, Hal. 87-97 ISSN 2656-2855
90 e-ISSN 2685-5518
INFORMATIKA DAN RPL, Vol. 2, No. 2, September 2020, Hal. 87-97 ISSN 2656-2855
dari perusahaan dan selanjutnya Alur sistem yang akan dijalankan oleh
mengutamakan lokasi yang jaraknya paling setiap aktor digambarkan dalam bentuk activity
dekat dengan lokasi yang dikunjungi diagram yang ditunjukkan pada Gambar 1.
terakhir. Sehingga diperoleh rute G -> 2 -> Pelanggan melakukan pemesanan dengan
5 -> 3 -> 4 -> 1 -> G dimana untuk menentukan pilih pesanan serta metode
menentukan panjang jarak dapat dilihat pada pembayaran yang akan digunakan, setelah
tabel 2 sehingga diperoleh panjang jarak pelanggan melakukan submit pesanan maka
1.92 + 1.88 + 0.13 + 0.40 + 13.77 + 15.70 = daftar pesanan akan masuk ke bagian
33.8 km. administrasi. Administrasi akan melakukan
pengecekan apakah pelanggan yang melakukan
3.3 Metode Pengembangan Sistem pemesanan pernah melakukan pemesanan atau
Dalam perancangan aplikasi ini, penulis belum, dan jika pernah apakah masih ada
mengimplementasikan metode Waterfall atau piutang atau tidak. Setelah administrasi
classic life cycle sebagai metode pengembangan melakukan persetujuan pesanan maka admin
perangkat lunak yang meliputi tahap : AE akan membuatkan faktur bagi pelanggan
1. Analisa Kebutuhan (Analysis) yang melakukan pemesanan dengan metode
2. Desain Sistem (Design) pembayaran cash. Selanjutnya administrasi
3. Pemrograman (Coding) akan membuat jadwal distribusi dimana pada
4. Pengujian (Testing) bagian ini akan dilakukan perhitungan dengan
metode saving matrix yang akan menghasilkan
Pemodelan sistem dilakukan dengan jadwal pengiriman hari A dengan armada A dan
menggunakan metode UML yang meliputi rute yang akan dilalui. Setelah jadwal dibuat
usecase diagram, sequence diagram dan class maka administrasi akan membuat surat faktur
diagram. sesuai rute yang akan dilewati.
Logistik melakukan pengiriman sesuai
HASIL DAN PEMBAHASAN rute yang telah ditentukan dimana pada setiap
Hasil dari penelitian ini yaitu Sistem titik penurunan barang logistik diharuskan
Manajemen Armada yang dapat menampilkan update tracking dengan melakukan konfirmasi
laporan rekap pesanan secara realtime, bahwa barang telah diterima oleh pelanggan
menampilkan jadwal dengan memberikan rute serta mengirimkan bukti konfirmasi sebagai
optimal distribusi dan laporan rekap jadwal penanda barang telah terkirim.
serta memonitoring proses pengiriman barang. Kebutuhan pengguna serta kebutuhan
dari alur proses yang telah dijelaskan diatas di
4.1 Kebutuhan Sistem dalam sebuah sistem disebut dengan kebutuhan
Tahapan ini didapatkan dari hasil fungsional. Dimana kebutuhan sistem yang
pengumpulan data yang dijelaskan pada dibangun : Kelola Pengguna, Kelola Pelanggan,
langkah metode penelitian dimana setelah Kelola Pemesanan Beverage, Kelola
dianalisa sistem manajemen armada ini Pemesanan Non Food, Daftar Pesanan, Kelola
memiliki enam aktor yaitu super admin, Armada, Kelola Jadwal Distribusi, Kelola Surat
pelanggan, administrasi, admin AE, logistik Jalan, Kelola Tracking, Kelola Faktur, Kelola
serta manager. Barang dan Kelola Servis. Dimana setiap
pengguna mempunyai role hak akses yang
berbeda – beda dalam mengoperasikan sistem
ini, untuk lebih jelasnya lagi dapat dilihat pada
use case pada gambar 2.
92 e-ISSN 2685-5518
INFORMATIKA DAN RPL, Vol. 2, No. 2, September 2020, Hal. 87-97 ISSN 2656-2855
94 e-ISSN 2685-5518
INFORMATIKA DAN RPL, Vol. 2, No. 2, September 2020, Hal. 87-97 ISSN 2656-2855
UAT (User Acceptance Test) adalah perangkat lunak itu sendiri. Pengujian white box
suatu proses pengujian yang dilakukan oleh dilakukan untuk meyakinkan semua statement
pengguna dengan hasil output sebuah dokumen dan kondisi dieksekusi secara optimal. Karena
uji yang dapat dijadikan bukti bahwa perangkat keterbatasan dalam penulisan maka yang
lunak sudah diterima dan sudah memenuhi disampaikan yaitu pengujian pada function
kebutuhan yang diminta. User Acceptance Test metode_penjadwalan bagian perhitungan
yang telah dilakukan dapat dilihat pada tabel 5. saving matrix. Berikut penentuan blok kode
program, source code sebagai berikut :
Tabel 5. Pengujian UAT
User Accepta Notable User customer_result = array();
atau nce Rate Comments hitung_customer = count($customer);
Tester for ($i=0; $i < $hitung_customer; $i++) {
Super (7 dari 9) “Akan lebih baik $hitung_isi_customer= count ($customer
Aktor 2.
Admin 77,8% jika form latitude [$i]);
dan longitude dapat 2 . $counter_gudang = 0;
terisi secara for ($j=0; $j < $hitung_isi_customer;
otomatis saat $j++) {
memasukan alamat” $hasil = 0;
Pelangg (7 dari 8) “Tampilan cukup
Aktor $gudang_1_counter = $jarak
an 87,5% menarik, tapi lebih
bagus jika code 5 3. gudang[$i]- >jarak_gudang;
order sudah tersedia $gudang_2_counter= $jarak_
3.
sehingga tidak perlu gudang[$counter_gudang]-
copy-paste code >jarak_gudang;
order lagi jadi $jarak_customer = $customer[$i]
tinggal langsung [$counter_gudang];
lacak order” 4. if($jarak_customer != 0){
Admini (11 dari “Cukup bagus dan $hasil = $gudang_1_
Aktor . 4
strator 12) penentuan rute
4 counter+ $gudang_2_counter
91,7% jadwal mudah 2
dimengerti, sayang - $jarak_customer;
5. 5 }
tampilan dashboard 1
polos” 2 $object_data = new stdClass();
Admin (2 dari 3) “Sangat membantu $object_data->id_start =
Aktor 1
AE 66,7% dimana saat akan $jarak_gudang
membuat faktur 3 [$i]->order_id;
data pelanggan $object_data->id_end =
tidak perlu ditulis $jarak_gudang
ulang, bagusnya 6. [$counter_gudang]->order_id;
tambah nama pada
tabel yang disajikan $object_data->total_start =
awal” $jarak_gudang[$i]->total_dus;
6
Logistik (8 dari 10) “Tambahkan $object_data->total_end =
Aktor 2
80% notifikasi jika pada $jarak_gudang
satu hari list 6 [$counter_gudang]->total_dus;
tracking masih ada
1
$object_data->jarak =
yang belum (float)$hasil;
dikonfirmasi” array_push($customer_result,
Manage (2 dari 2) “Modul laporan
Aktor $object_data);
r 100% yang disajikan
mudah dimengerti 1 $counter_gudang++;
untuk membantu 7. }
dalam analisa tiap 7}
bulan atau 2
96 e-ISSN 2685-5518
INFORMATIKA DAN RPL, Vol. 2, No. 2, September 2020, Hal. 87-97 ISSN 2656-2855