• Tidak ada hasil yang ditemukan

BAB IV HASIL DAN PEMBAHASAN

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB IV HASIL DAN PEMBAHASAN"

Copied!
37
0
0

Teks penuh

(1)

BAB IV

HASIL DAN PEMBAHASAN

Bab ini membahas secara rinci sistem yang diusulkan yaitu sistem pengendalian persediaan menggunakan metode least square regression line dan

economic order quantity. Bagian pertama menampilkan hasil yang telah diperoleh

yang terdiri dari identifikasi potensi yang dimiliki perusahaan dan masalah yang sedang terjadi, analisis data yang telah diperoleh, rancangan desain sistem pengendaliaan persediaan yang diusulkan berdasarkan analisis data yang telah dilakukan sebelumnya dilanjutkan dengan pembuatan aplikasi dan pengujian sistem menggunakan black box testing. Bagian kedua pembahasan secara keseluruhan hasil yang diperoleh pada penelitian ini.

4.1 Hasil

4.1.1 Identifikasi Potensi dan Masalah

Perusahaan Mitra Mandiri menggunakan sistem berbasis komputer untuk melakukan pencatatan transaksi penjualan dan pembelian. Dengan demikian kebutuhan untuk menjalankan sistem yang diusulkan telah dimiliki oleh perusahaan seperti komputer, print, laptop dan lain-lain. Dengan adanya user atau karyawan perusahaan yang sudah terbiasa menggunakan pencatatan berbasis komputer akan memudahkan implementasi sistem yang diusulkan.

(2)

Permasalahan yang sering timbul pada sistem pengendalian perusahaan sebelumnya adalah jumlah atau kuantitas pesanan yang tidak sesuai dengan kebutuhan pelanggan. Hal tersebut terjadi karena jumlah pemesanan hanya berdasarkan perkiraan manajer atau pimpinan. Dengan waktu pengiriman pesanan yang relatif lama membuat perusaan sering kali mendapat keluhan dari pelanggan atau sub distributor karena kebutuhan akan pupuk sangat mendesak. Daftar permasalahan sistem pengendalian yang telah diterapkan oleh perusahaan dapat dilihat pada tabel 4.1.

Tabel 4.1. Daftar Permasalahan

No. Permasalahan

1. Tidak bisa memprediksi jumlah permintaan.

2. Tidak bisa menentukan kuantitas pesanan yang optimum 3. Jumlah persediaan tidak sesuai dengan permitaan. 4. Tidak bisa menentukan titik pemesanan.

5. Besarnya total biaya persediaan.

4.1.2 Analisis Data

Analisis data dilakukan melalui beberapa tahapan antara lain analisis autokorelasi untuk mengetahui pola data, analisis kesalahan prediksi guna mengetahui tingkat keakuratan prediksi dan terakhir analisis biaya persediaan yang bertujuan membandingkan biaya persediaan pada perusahaan dengan biaya persediaan menggunakan metode EOQ.

(3)

1. Analisis Autokorelasi

Sebelum dilakukan uji keakuratan prediksi dan analisis biaya persediaan akan dilakukan Analisis autokorelasi pada data penjualan pupuk dari tahun 2010 sampai tahun 2012. Analisis tersebut bertujuan untuk pengetahui apakah pada data penjualan terdapat pola tren, musiman, acak ataupun konstan. Dari hasil pola data tersebut selain untuk mengetahui apakah metode LSRL cocok digunakan, juga nantinya akan mempengaruhi desain sistem yang akan dibuat. Misalnya jika pada data terdapat pola musiman pada desain sistem juga data penjualan akan diakumulasikan 4 bulanan. Hal tersebut dikarenakan pola data merupakan komponen dari metode peramalan yang mempengaruhi keakuratan hasil ramalan. Data penjualan yang akan dilakukan analisis autokorelasi disajikan pada tabel 4.2.

Tabel 4.2 Data Penjualan Pupuk

Bulan

Penjualan Pupuk

Tahun 2010 Tahun 2011 Tahun 2012 1. Bintang Sawit (Zak)

Januari 98 102 142 Februari 94 93 139 Maret 118 144 231 April 103 135 218 Mei 143 192 189 Juni 114 150 272 Juli 141 103 151 Agustus 109 223 228 September 179 169 176 Oktober 167 175 186 November 149 186 225 Desember 165 213 292 2. Niposca (Zak)

(4)

Bulan

Penjualan Pupuk

Tahun 2010 Tahun 2011 Tahun 2012

Januari 187 131 221 Februari 63 103 219 Maret 163 161 234 April 158 187 251 Mei 181 190 263 Juni 189 216 318 Juli 103 229 221 Agustus 174 183 186 September 199 134 211 Oktober 159 190 299 November 202 282 253 Desember 138 321 373 3. Bioposka (Zak) Januari 58 91 138 Februari 136 121 173 Maret 187 164 161 April 98 199 165 Mei 172 203 185 Juni 146 80 141 Juli 194 102 180 Agustus 120 192 203 September 89 228 243 Oktober 90 152 145 November 182 215 193 Desember 120 173 250

4. Grend Leaf (Botol)

Januari 407 203 503 Februari 602 548 517 Maret 503 451 130 April 438 302 474 Mei 394 445 693 Juni 470 542 765 Juli 416 579 685

(5)

Bulan

Penjualan Pupuk

Tahun 2010 Tahun 2011 Tahun 2012

Agustus 532 621 631

September 653 401 497

Oktober 502 587 708

November 316 486 639

Desember 703 590 843

Sumber: Buku Pembelian dan Penjualan, Mitra Mandiri, 2013

Dari tabel 4.2 terlihat bahwa jumlah penjualan diakumulasikan dalam bulanan dari tahun 2010 sampai 2012. Berdasarkan data penjualan akan dihitung

time lag (Lampiran 1). Untuk mengetahui apakah data penjualan tersebut

mempunyai pola musiman dibutuhkan perhitungan hingga time lag 12 karena data penjualan disajikan dalam bulanan. Hasil dari perhitungan jumlah dari data aktual dikurangi dengan nilai rata-rata penjualan perbulan kemudian dikuadratkan dapat dilihat pada tabel 4.3.

Tabel 4.3 Data Variabel A

Variabel Bintang Sawit Niposca Bioposka Grend Leaf

(Yt − Ȳ)2 89185,222 146848,889 79088,972 785304,889

Setelah jumlah dari data aktual dikurangi dengan nilai rata-rata penjualan perbulan dikuadratkan diketahui selanjutnya akan dihitung jumlah dari perkalian data aktual dikurangi dengan nilai rata-rata dengan data time lag 1 dikurangi dengan nilai rata-rata. Perhitungan yang sama dilakukan pada time lag 2 hingga 12 .Hasil dari perhitungan tersebut dapat dilihat pada tabel 4.4

(6)

Tabel 4.4 Data Variabel B

Variabel Bintang

Sawit Niposca Bioposka Grend Leaf

Yt− Ȳ (Yt−1− Ȳ) 32038,367 72616,247 15401,749 85697,136 Yt− Ȳ (Yt−2− Ȳ) 30658,790 44350,049 -6925,890 121431,383 Yt− Ȳ (Yt−3− Ȳ) 30814,046 24051,963 8667,553 -34133,037 Yt− Ȳ (Yt−4− Ȳ) 21690,358 34172,210 17735,247 702,210 Yt− Ȳ (Yt−5− Ȳ) 20911,225 56677,346 13255,885 78250,457 Yt− Ȳ (Yt−6− Ȳ) 31024,648 65736,370 6871,162 208693,926 Yt− Ȳ Yt−7− Ȳ 19807,182 44014,506 -3327,311 -86885,160 Yt− Ȳ (Yt−8− Ȳ) 17917,772 23593,531 6366,383 -50781,802 Yt− Ȳ (Yt−9− Ȳ) 7869,861 1952,778 17822,660 -179120,889 Yt− Ȳ (Yt−10− Ȳ) 9064,228 15732,358 6568,853 188676,025 Yt− Ȳ (Yt−11− Ȳ) 4428,040 22347,494 -5779,064 66935,605 Yt− Ȳ (Yt−12− Ȳ) 21776,130 27451,185 13193,324 153531,407

Setalah variabel yang dibutuhkan didapatkan kemudan dimasukan pada persamaan 15 dengan data penjualan dari time lag 1 hingga time lag 12. Hasil dari koefisien autokorelasi dapat dilihat pada tabel 4.5

Tabel 4.5 Data Koefisien Autokorelasi

Time Lag

Autokorelasi

Bintang Sawit Niposca Bioposca Grend Leaf

1 0,359 0,494 0,195 0,109 2 0,344 0,302 -0,088 0,155 3 0,346 0,164 0,110 -0,043 4 0,243 0,233 0,224 0,001 5 0,234 0,386 0,168 0,100 6 0,348 0,448 0,087 0,266 7 0,222 0,300 -0,042 -0,111 8 0,201 0,161 0,080 -0,065 9 0,088 0,013 0,225 -0,228 10 0,102 0,107 0,083 0,240 11 0,050 0,152 -0,073 0,085 12 0,244 0,187 0,167 0,196

(7)

Kesalahan standar untuk time lag 1 dihitung menggunakan persamaan 16 dengan tingkat keyakinan 95 % adalah 0,326667, hasil tersebut didapatkan dari 1,96 X 1 / 36. Nilai 1,96 didapatkan dari tabel Z dengan 95% tingkat keyakinan. Demikian juga untuk time lag 2 hingga 12 pada data penjualan empat produk dihitung menggunakan cara yang sama yaitu menggunakan persamaan 16 dengan tingkat keyakinan 95 %.

Dengan menggunakan kesalahan standar 0,326667 maka dapat ditentukan apakah koefisien korelasi pada time lag 1 berbeda nyata dengan nol atau tidak. Jika koefisien autokorelasi lebih besar dari nilai kesalah standar maka koefisien autokorelasi berbeda nyata dengan nol, tetapi sebaliknya apabila koefisien autokorelasi berada diantara plus minus nilai kesalahan standar maka koefisien autorkorelasi tersebut tidak berbeda nyata dengan nol.

Dari tabel 4.5 dapat disimpulkan bahwa data penjualan Niposca dan Bintang Sawit memiliki pola tren dan bersifat konstan karena pada lag pertama koefisien autokorelasi berbeda nyata dengan nol dan berangsur-angsur mendekati nol. Sedangkan pada data penjualan Bioposka dan Grend Leaf memiliki pola tren dan data bersifat acak karena koefisien autokorelasi pada time lag 1 berada diantara plus minus nilai kesalahan standar pada time lag 1. Selanjutnya time lag ke 12 koefisien autokorelasi tidak berbeda nyata dengan nol hal tersebut menunjukan bahwa data penjualan tidak memiliki pola musiman.

(8)

2. Uji Keakuratan

Uji Keakuratan dibutuhkan untuk mengetahui seberapa akurat prediksi yang dilakukan, uji kali ini dilakukan menggunakan metode MSE. Pengujian keakuratan akan dilakukan pada hasil prediksi menggunakan metode LSRL (Lampiran 2). Data penjualan bulanan akan diakumulasikan menjadi data penjualan tahunan karena prediksi penjualan yang akan dilakukan adalah penjualan tahunan. Hasil perhitungan kesalahan prediksi dapat dilihat pada tabel 4.6

Tabel 4.6 Kesalahan Prediksi Periode Permintaan (𝐷𝑡) Ramalan (𝐹𝑡) Kesalahan 𝐷𝑡− 𝐹𝑡 Kesalahan2 𝐷𝑡− 𝐹𝑡 2 1. Bintang Sawit 1 1580 1536,833 43,16667 1863,361 2 1885 1971,333 -86,3333 7453,444 3 2449 2405,833 43,16667 1863,361 2. Niposca 1 1916 1864,167 51,83333 2686,694 2 2327 2430,667 -103,667 10746,78 3 3049 2997,167 51,83333 2686,694 3. Bioposka 1 1592 1603,833 -11,8333 140,0278 2 1920 1896,333 23,66667 560,1111 3 2177 2188,833 -11,8333 140,0278 4. Grend Leaf 1 5936 5684,167 251,8333 63420,03 2 5755 6258,667 -503,667 253680,1 3 7085 6833,167 251,8333 63420,03

Dari hasil perhitungan kesalahan prediksi akan dihitung nilai kesalahan pangkat rata-rata pada hasil prediksi yang menggunakan metode LSRL. Nilai

(9)

yang telah didapatkan dimasukan pada persamaan 14. Hasil dari perhitungan nilai pangkat rata-rata (MSE) dapat dilihat pada tabel 4.7.

Tabel 4.7 Nilai MSE

Nilai Bintang Sawit Niposca Bioposka Grend Leaf

MSE 3726,722 5373,389 280,056 126840,1

Dari tabel 4.7 dapat dilihat bahwa hasil prediksi pada data penjualan Bioposka mendekati data aktual dengan nilai kesalahan rata-rata 280,056 sedangkan nilai kesalahan rata-rata tersebesar terdapat pada data penjualan Grend Leaf dengan nilai 126840,1. Dari hasil tersebut menunjukan ada kecenderungan nilai kesalahan rata-rata berbanding lurus dengan jumlah penjualan atau dengan kata lain semakin besar jumlah penjualan akan semakin besar juga nilai kesalahan rata-rata. Disamping itu, jika dipresentasekan (Lampiran 3) rata-rata kesalahan prediksi dari keempat produk tersebut sebesar 2,9 % sehingga rata-rata keakuratan prediksi sebesar 97,1 %.

3. Analisis Biaya Persediaan

Analisis biaya persediaan akan dilakukan pada data penjualan satu tahun terakhir yaitu tahun 2012 hal tersebut dikarenakan metode EOQ mencakup biaya persediaan tahunan. Biaya persediaan sendiri terdiri dari biaya pemesanan dan biaya penyimpanan. Biaya persediaan diasumsikan tidak berubah dalam waktu satu tahun karena metode EOQ merupakan hasil akar, perubahan biaya persediaan dibahawah 10 % tidak akan berpengaruh secara signifikan terhadap hasil EOQ. Rincian biaya pemesanan yang dikeluarkan oleh perusahaan untuk sekali pemesanan dapat dilihat pada tabel 4.8.

(10)

Tabel 4.8 Rincian Biaya Pemesanan

No Jenis Biaya Jumlah Biaya (Rp)

1 Biaya Telepon 100.000

2 Biaya Pemeriksaan 450.000

3 Biaya Administrasi 1.000.000

Total 1.550.000

Dari tabel 4.8 dapat terlihat bahwa biaya pemesanan untuk sekali pengiriman barang sebesar Rp. 1.550.000. biaya tersebut terdiri dari biaya telepon, pemeriksaan dan administrasi. Biaya telepon digunakan untuk komunikasi pada saat pemesanan barang berlangsung, biaya tersebut diasumsikan Rp. 100.000 untuk setiap kali pemesanan karena proses komunikasi terjadi berulang-ulang sehingga dapat menghabiskan biaya yang relatif besar. Selain itu biaya pemeriksaan digunakan oleh perusahaan membayar pegawai untuk memeriksa kuantitas dan kualitas produk yang diterima oleh perusahaan. Sedangkan biaya administrasi digunakan oleh perusahaan sebagai biaya pengurusan dokumen-dokumen yang berhubungan dengan pemesanan dan pengiriman barang.

Selanjutnya akan dihitung biaya penyimpanan yang digunakan perusahaan (Lampiran 4). Biaya penyimpanan merupakan biaya yang habis digunakan untuk penyimpanan produk sebelum dijual. Biaya penyimpanan terdiri dari biaya kesempatan, biaya penyusutan fasilitas, biaya listrik dan biaya pelaksana gudang. Biaya kesempatan merupakan biaya yang didapatkan apabila modal disimpan di bank, dengan asumsi bunga pertahun 7,5 %. sedangkan fasilitas penyimpanan yang dihitung pada biaya penyusutan adalah tempat penyimpanan berupa gudang.

(11)

Rincian biaya penyimpanan untuk masing-masing produk dapat dilihat pada tabel 4.9

Tabel 4.9 Rincian Biaya Penyimpanan

No Jenis Biaya

Biaya Penyimpanan Bintang

Sawit Niposca Bioposka Grend Leaf (Rp/Zak/ Tahun) (Rp/Zak/ Tahun) (Rp/Zak/ Tahun) (Rp/Botol/ Tahun) 1 Biaya Kesempatan (Opportunity Cost) 3389,75 4283,75 4842,5 1117,5

2 Biaya Penyusutan Fasilitas 187,58 195,08 314,4 869,56

3 Biaya Listrik 35,17 36,58 58,95 163,04

4 Biaya Pelaksana Gudang 351,73 365,77 589,5 1630.43

Total 3964,23 4881,18 5805,35 2150,1

Dari tabel 4.9 dapat dilihat bahwa total biaya penyimpanan terbesar dihasilkan oleh produk Bioposka dengan jumlah Rp. 5805,35. Hal tersebut terjadi karena persediaan rata-rata pertahun untuk produk Bioposka lebih besar jika dibandingkan dengan Niposca ataupun Bintang Sawit yang mempunyai harga hampir sama. Sedangkan biaya penyimpanan terkecil dihasilkan oleh produk Grend Leaf sebesar Rp. 2150,1. Hal tersebut terjadi karena meskipun tingkat persediaan rata-rata Grend Leaf besar akan tetapi harga per unitnya lebih murah jika dibandingkan dengan 3 produk lainnya. Selain itu jika dilihat dari biaya penyusunnya, biaya kesempatan memberikan konstribusi terbesar. Hal tersebut terjadi karena harga pembelian pupuk yang mahal sehingga apabila pupuk tersimpan dalam jumlah yang besar akan menghasilkan biasa kesempatan yang besar pula.

(12)

Setelah didapat biaya penyimpanan perunit kemudian akan dihitung total biaya penyimpanan dengan mengalikan biaya penyimpan per unit dengan tingkat persediaan rata-rata atau Q/2. Total biaya penyimpanan untuk masing-masing produk dapat dilihat pada tabel 4.10.

Tabel 4.10 Total Biaya Penyimpanan

No Pupuk Biaya Penyimpanan Per Unit (Rp) Tingkat Persediaan Rata-rata Jumlah Biaya Penyimpanan 1 Bintang Sawit 3964,23 611,45 2423928,43 2 Niposca 4881,18 635,87 3103795,93 3 Bioposka 5805,35 1024,79 5949264,63 4 Grend Leaf 2150,1 2834,37 6094178,94 Total 17571167,92

Total biaya penyimpanan terbesar diberikan oleh produk Grend Leaf karena produk tersebut memiliki tingkat persediaan yang paling besar. Dari total biaya pengiriman dan total biaya penyimpanan kemudian akan dihitung total biaya persediaan dengan cara menjumlahkan total biaya pengiriman dan total biaya penyimpanan. Total biaya persediaan yang dikeluarkan oleh perusahaan selama tahun 2012 dapat dilihat pada tabel 4.11.

Tabel 4.11 Total Biaya Persediaan

No Pupuk Total Biaya Pemesanan/Ta hun (Rp) Total Biaya Penyimpanan/Tah un (Rp) Total Biaya Persediaan 1 Bintang Sawit 3954114,58 2423928,43 6378043,01 2 Niposca 4922864,58 3103795,93 8026660,51 3 Bioposka 3514947,92 5949264,63 9464212,55 4 Grend Leaf 1906553,82 6094178,94 8000732,76 Total 31.869.648,83

(13)

Total biaya persediaan selama tahun 2012 yang dikeluarkan oleh perusahaan sebesar Rp. 31.869.648,83. Biaya tersebut merupakan total dari keempat produk yang dijual oleh perusahaan. Pupuk Bioposka menghasilkan biaya persediaan yang paling besar karena jika dilihat dari segi harga dan tingkat persediaan produk tersebut memiliki nilai yang besar jika dibandingkan dengan tiga produk lainnya.

Selanjutnya setelah total biaya persediaan aktual diketahui akan dihitung total biaya persediaan jika perusahaan menerapkan metode economic order

quantity untuk menentukan kuantitas pesanan. Kuantitas pesanan optimal pada

masing-masing produk dengan menggunakan metode EOQ dapat dilihat pada tabel 4.12

Tabel 4.12 Kuantitas Pesanan Optimal

No Pupuk Jumlah Penjualan (D) Biaya Pemesanan/ Tahun (Rp) (Co) Biaya Penyimpanan/ Tahun (Rp) (Cc) EOQ Qopt = 𝟐𝑪𝒐𝑫 𝑪𝒄 1 Bintang Sawit 2449 1550000 3964,23 1383,87 2 Niposca 3049 1550000 4881,18 1391,54 3 Bioposka 2177 1550000 5805,35 1078,19 4 Grend Leaf 7085 1550000 2150,1 3196,11

Kuantitas pesanan optimal untuk masing-masing produk akan digunakan untuk menghitung total biaya penyimpanan dan total biaya pemesanan. Total biaya pemesanan didapat dari hasil kali biaya untuk sekali pemesanan dengan jumlah penjualan pertahun dibagi dengan kuantitas pesanan optimal. Sedangkan total biaya penyimpanan didapatkan dari hasil kali biaya penyimpanan dikalikan dengan kuantitas optimal dibagi dua. Hasil dari total biaya penyimpanan dan total

(14)

biaya persediaan akan dijumlahkan untuk mendapatkan total biaya persediaan minimum. Perbandingan total biaya persediaan aktual dan total biaya persediaan menggunakan metode economic order quantity dapat dilihat pada tabel 4.13.

Tabel 4.13 Perbandingan Total Biaya Persediaan

No Pupuk Total Biaya Persediaan Perusahaan (Rp) Total Biaya Persediaan EOQ (Rp) Penghematan 1 Bintang Sawit 6378043,01 5485985,58 892057,43 2 Niposca 8026660,51 6792379,94 1234280,57 3 Bioposka 9464212,55 6259278,36 3204934,19 4 Grend Leaf 8000732,76 6871951,79 1128780,97 Total 31869648,83 25409595,67 6460053,16

Tabel 4.13 menunjukan bahwa total biaya persediaan aktual sebesar Rp 31.869.648,83 sedangkan total biaya persediaan EOQ sebesar Rp. 25.409.595,67 dengan demikian, perusahaan akan dapat menghemat biaya sebesar Rp Rp. 6.460.053,16 jika perusahaan menerapkan metode economic order quantity dalam menentukan kuantitas pemesanan.

4.1.3 Desain Sistem

Desain sistem baru akan digambarkan menggunakan use case diagram,

use case spesification, component diagram dan deployment diagram.

1. Use Case Diagram

Use case diagram akan menjelaskan tugas dari masing-masing aktor. Use

(15)

Gambar 4.1 Use Case Diagram

Dari gambar 4.1 terlihat bahwa user terbagi menjadi empat yaitu admin, sekretaris, pimpinan dan bagian gudang. Masing-masing user tersebut mempunyai hak akses yang berbeda-beda. Hak akses untuk menghitung perencanaan stok hanya bisa dilakukan oleh user sekretaris, sedangkan input data barang, input barang keluar dan input barang masuk hanya bisa dilakukan oleh user bagian gudang. Hak akses melihat laporan perencanaan stok dimiliki oleh user sekretaris dan pimpinan, disamping itu pimpinan juga memiliki hak akses untuk melihat laporan keluar masuk barang yang juga dimiliki oleh user bagian gudang.

User admin sendiri hanya bertugas untuk melakukan manajemen user seperti menambah, merubah ataupun menghapus user. Disamping itu semua user yang terbagi atas sekretaris, pimpinan, bagian gudang dan adimin dapat merubah password dan melakukan login. Untuk langkah-langkah masing-masing use case akan dijelakan pada use case spesification.

(16)

2. Use Case Spesification

Tahap ini akan menjelaskan secara lebih rinci masing-masing use case seperti yang terlihat pada gambar 4.1.

A. Use Case Specification: Input Data Barang (1) Use Case Name

Use case Input Data Barang menunjukkan bagaimana bagian gudang berinteraksi dengan sistem saat pegawai gudang akan mengimput data barang.

(2) Flow of Events i) Basic Flow

Tabel 4.14 Flow of Event Use case Input Data Barang

User Sistem

1. Use Case ini akan dimulai ketika pegawai gudang memilih menu barang

2. Sistem akan memberikan form inputan yang terdiri dari nama barang dan jenis barang

3. Pegawai gudang mengisikan sesuai data barang yang akan diinputkan lalu memilih tombol daftar

4. Sistem akan memeriksa inputan dan jika sesuai selanjutnya akan menyimpan data barang.selesai

ii) Alternative Flows

pegawai gudang dapat mengedit ataupun menghapus data barang jika data

barang yang diiput terdapat kesalahan.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(17)

(4) Preconditions

Pegawai gudang sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(5) Post Conditions

Pada akhir dari use case ini, pegawai gudang akan dapat menambahkan data barang.

B. Use Case Specification: Melihat Laporan Keluar Masuk Barang (1) Use Case Name

Use case Melihat Laporan Keluar Masuk Barang menunjukkan bagaimana bagian gudang berinteraksi dengan sistem saat bagian gudang akan melihat laporan keluar masuk barang.

(2) Flow of Events i) Basic Flow

Tabel 4.15 Flow of Event Use case Melihat Laporan Keluar Masuk Barang

User Sistem

1. Use Case ini akan dimulai ketika bagian gudang memilih menu laporan bulanan

2. Sistem akan memberikan form inputan yang terdiri dari laporan, cari tanggal dan hingga

3. Pegawai gudang mengisikan sesuai data barang dan rentang tanggal yang diinginkan.

4. Sistem akan menampilkan laporan barang sesuai inputan pegawai gudang yang terdiri dari tanggal transaksi, kode barang, nama barang dan jumlah.

(18)

ii) Alternative Flows

Bagian gudang dapat memilih menu laporan kemudian memilih laporan keluar masuk barang untuk melihat laporan keluar masuk barang.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

Pegawai gudang sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(5) Post Conditions

Pada akhir dari use case ini, pegawai gudang akan dapat melihat laporan keluar masuk barang.

C. Use Case Specification: Input Barang Masuk (1) Use Case Name

Use case Input Barang Masuk menunjukkan bagaimana bagian gudang berinteraksi dengan sistem saat bagian gudang akan memasukan data barang masuk.

(2) Flow of Events i) Basic Flow

Tabel 4.16 Flow of Event Use Case Input Barang Masuk

User Sistem

1. Use Case ini akan dimulai ketika bagian gudang memilih menu penerimaan barang.

(19)

User Sistem

2. Sistem akan memberikan form inputan yang terdiri dari tanggal, kode barang, nama barang dan kuantitas.

3. Bagian gudang mengimputkan tanggal, kuantitas dan memilih kode barang.

4. Sistem akan menampilkan data barang berupa nama barang, jenis barang dan jumlah persediaan. 5. bagian gudang memilih nama

barang yang diinginkan.

6. Sistem akan memasukan data barang yang dipilih kedalam form inputan kode barang dan nama barang.

7. Bagian gudang mengklik tombol tambah.

8. Sistem akan menyimpan data barang masuk sesuai inputan. Selesai

ii) Alternative Flows

Bagian gudang dapat memilih menu transaksi kemudian memilih barang masuk untuk memasukan data barang masuk.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

Pegawai gudang sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(20)

Pada akhir dari use case ini, bagian gudang akan dapat mengimputkan data barang masuk.

D. Use Case Specification: Input Barang Keluar (1) Use Case Name

Use case Input Barang Keluar menunjukkan bagaimana bagian gudang berinteraksi dengan sistem saat bagian gudang akan memasukan data barang keluar.

(2) Flow of Events i) Basic Flow

Tabel 4.17 Flow of Event Use Case Input Barang Keluar

User Sistem

1. Use Case ini akan dimulai ketika bagian gudang memilih menu keluar barang.

2. Sistem akan memberikan form inputan yang terdiri dari tanggal, kode barang, nama barang dan kuantitas.

3. Bagian gudang mengimputkan tanggal, kuantitas dan memilih kode barang.

4. Sistem akan menampilkan data barang berupa nama barang, jenis barang dan jumlah persediaan. 5. bagian gudang memilih nama

barang yang diinginkan.

6. Sistem akan memasukan data barang yang dipilih kedalam form inputan kode barang dan nama barang.

7. Bagian gudang mengklik tombol tambah.

8. Sistem akan menyimpan data barang keluar sesuai inputan.

(21)

Selesai

ii) Alternative Flows

Bagian gudang dapat memilih menu transaksi kemudian memilih barang keluar untuk memasukan data barang keluar.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

Pegawai gudang sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(5) Post Conditions

Pada akhir dari use case ini, bagian gudang akan dapat mengimputkan data barang keluar.

E. Use Case Specification: Melihat Laporan Perencanaan Persediaan (1) Use Case Name

Use case Melihat Laporan Perencanaan Stok menunjukkan bagaimana sektretaris dan pimpinan berinteraksi dengan sistem saat user akan melihat laporan perencanaan persediaan.

(2) Flow of Events i) Basic Flow

Tabel 4.18 Flow of Event Use Case Melihat Laporan Perencanaan Persediaan

(22)

1. Use Case ini akan dimulai ketika sekretaris atau pimpinan memilih menu laporan EOQ

2. Sistem akan menampilkan laporan data perencanaan yang terdiri dari nama barang, rata-rata penjualan,prediksi penjualan,total biaya persediaan, tersedia, stok cadangan, dan EOQ.

ii) Alternative Flows

sekretaris atau pimpinan dapat memilih menu laporan kemudian memilih economic order quantity untuk melihat laporan data perencanaan.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

Sekretaris atau pimpinan sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(5) Post Conditions

Pada akhir dari use case ini, sekretaris atau pimpinan akan dapat melihat laporan data perencanaan.

F. Use Case Specification: Input Data User (1) Use Case Name

Use case Input Data User menunjukkan bagaimana admin berinteraksi dengan sistem saat admin akan mengimput data user.

(23)

i) Basic Flow

Tabel 4.19 Flow of Event Use Case Input Data User

User Sistem

1. Use Case ini akan dimulai ketika admin memilih menu user management

2. Sistem akan memberikan form inputan yang terdiri dari username, password dan jenis login.

3. Admin mengisikan sesuai data user yang akan diinputkan lalu memilih tombol daftar

4. Sistem akan memeriksa inputan dan jika sesuai selanjutnya akan menyimpan data barang.selesai

ii) Alternative Flows

 Admin dapat mengedit ataupun menghapus data barang jika data user yang diiput terdapat kesalahan.

 Admin memilih menu sistem kemudian memilih user management untuk melakukan pengimputan data user.

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

Admin sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(5) Post Conditions

(24)

G. Use Case Specification: Melakukan Login (1) Use Case Name

Use case Melakukan Login menunjukkan bagaimana user berinteraksi dengan sistem saat user akan melakukan login ke sistem.

(2) Flow of Events i) Basic Flow

Tabel 4.20 Flow of Event Use Case Melakukan Login

User Sistem

1. Use Case ini akan dimulai ketika user mulai membuka sistem

2. Sistem akan memberikan form inputan yang terdiri dari username dan password.

3. User mengisikan sesuai username dan password yang akan diinputkan lalu memilih tombol masuk.

4. Sistem akan memeriksa inputan dan jika sesuai selanjutnya akan menampilkan halaman yang sesuai dengan jenis user. selesai

ii) Alternative Flows

-

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

User sudah terdaftar dalam database.

(5) Post Conditions

(25)

H. Use Case Specification: Mengganti Password (1) Use Case Name

Use case Mengganti Password menunjukkan bagaimana user berinteraksi dengan sistem saat user akan mengganti password.

(2) Flow of Events i) Basic Flow

Tabel 4.21 Flow of Event Use Case Mengganti Password

User Sistem

1. Use Case ini akan dimulai ketika user memilih menu profil info dan memilih ubah password.

2. Sistem akan memberikan form inputan yang terdiri dari password lama dan password baru.

3. User mengisikan password lama dan baru.

4. Sistem akan memeriksa inputan dan jika sesuai selanjutnya akan menyimpan perubahan. selesai

ii) Alternative Flows

-

(3) Special Requirements

Komputer yang digunakan untuk mengakses sistem harus memiliki browser.

(4) Preconditions

User sudah melakukan otentikasi dengan menjalankan use case Melakukan Login.

(26)

Pada akhir dari use case ini, user akan dapat merubah password.

3. Component Diagram

Bagian ini akan menjelaskan ketergantungan antar komponen pada sistem baru. Dapat dilihat pada gambar 4.2 – 4.6 Component Diagram dari sistem pengendalian persediaan yang dibuat.

a. Component Diagram Barang

(27)

b. Component Diagram Barang Masuk

Gambar 4.3 Component Diagram Barang Masuk

c. Component Diagram Barang Keluar

(28)

d. Component Diagram User

Gambar 4.5 Component Diagram User

e. Component Diagram Perencanaan

(29)

Gambar 4.2 sampai 4.6 menunjukan bahwa system dibangun berbasis WEB. Class stereotypes yang digunakan terdiri dari server page, client page dan form. Secara umum component diagram yang digambarkan menunjukan hubungan antara server page, client page dan form. Server page sendiri berisi kode-kode PHP yang akan dijalankan berdasarkan permintaan yang dikirmkan oleh browser. Setelah file yang dikirmkan server page dimodelkan oleh client page, selanjutnya akan ditampilan dalam bentuk form htlm yang akan menerima masukan dari user. Proses terakhir adalah inputan yang diterima oleh form html dikirimkan ke server page untuk diproses.

4. Deployment Diagram

Deployment Diagram akan mewakili hubungan antara perangkat keras

ataupun perangkat lunak pada sistem baru. Sistem dibuat berbasis web sehingga akses sistem dapat dilakukan dimana saja dengan syarat terkoneksi dengan internet dan sudah terinstal web browser pada komputer atau laptop yang digunakan. Database yang akan digunakan adalah MySQL dengan bahasa pemrograman menggunakan PHP. Deployment Diagram sistem baru dapat dilihat pada gambar 4.7.

(30)

Gambar 4.7 Deployment Diagram 4.1.4 Pembuatan Aplikasi

Berdasarkan hasil dari tahapan desain sistem metode LSRL dan EOQ akan diterapkan pada aplikasi berbasis web dengan menggunakan bahasa pemrograman PHP dan database MySQL. Adapun hasil dari aplikasi pengendalian persediaan adalah sebagai berikut.

(31)

a.Tampilan Form Inputan Perencanaan Persediaan

Gambar 4.8 Inputan Perencaanaan Persediaan

b. Tampilan Form Inputan Barang Masuk

(32)

c. Tampilan Form Inputan Barang Keluar

Gambar 4.10 Inputan Barang Keluar

d. Hasil Laporan Perencanaan persediaan

(33)

e. Grafik Perencanaan Persediaan

Gambar 4.12 Grafik Perencanaan Persediaan

Aplikasi pengendalian persediaan yang telah dibuat dapat menghitung kuantitas pemesanan optimal, titik pemesanan ulang dan stok cadangan secara otomatis sehingga pimpinan dan sekretaris hanya tinggal melihat laporan yang dihasilkan oleh aplikasi. Laporan perencanaan dapat dilihat pada gambar 4.11. Selain dalam bentuk tabel aplikasi juga menyajikan dalam bentuk grafik seperti yang terlihat pada gambar 4.12.

Kuantitas pemesanan optimal yang dihasilkan oleh aplikasi dihitung berdasarkan data keluar masuk barang yang diinputkan oleh bagian gudang. Tampilan inputan keluar masuk barang dapat dilihat pada gambar 4.9 dan 4.10. Selain data keluar masuk barang, data perencanaan yang diinputkan oleh sekretaris juga menjadi penentu besaran kuantitas optimal. Data perencanaan yang diinputkan berupa tingkat pelayanan, biaya pengiriman, biaya pemesanan dan waktu tunggu dalam bulan. Tampilan inputan data perencanaan dapat dilihat pada gambar 4.8.

Dengan demikian laporan yang dihasilkan oleh sistem akan berubah sesuai dengan inputan keluar masuk barang pada tahun sebelumnya dan data

(34)

perencanaan. Data keluar masuk barang yang dibutuhkan oleh sistem untuk menentukan kuantitas optimal, titik pemesanan ulang dan stok cadangan minimal 2 tahun terakhir karena sistem menerapkan metode LSRL untuk melakukan ramalan penjualan sehingga membutuhkan minimal 2 tahun terakhir untuk melakukan prediksi atau ramalan penjualan.

4.1.5 Pengujian Sistem

Setelah sistem dapat diakses menggunakan web browser selanjutnya tahap pengujian sistem dilakukan untuk membuktikan apakah sistem dapat memproses inputan dan menghasilkan output sesuai dengan desain sistem. Pengujian sistem menggunakan black box testing, hasil dari pengujian dapat dilihat tabel 4.22.

Tabel 4.22. Hasil Pengujian Sistem

Input/Event Lankah Pengujian Output Output yang Seharusnya Hasil Pengujian Tambah Data Barang Login, Klik Barang, Input Data Barang, Klik

Daftar Data berhasil di simpan Data berhasil di simpan Sesuai Tambah Data Barang Masuk Login, Klik Barang Masuk, Input Data Barang

Masuk, Klik Daftar Data berhasil di simpan Data berhasil di simpan Sesuai Tambah Data Barang keluar Login, Klik Barang Keluar, Input Data Barang, Klik Daftar Data berhasil di simpan Data berhasil di simpan Sesuai Melakukan Login Mengimput username dan password Memproses inputan Memproses inputan Sesuai Mengganti Password Melakukan Login , mengganti password Password terganti Password terganti Sesuai Mengimput Data Perencanaan Login sebagai

sekretaris, Klik Data Tersimpan

Data

(35)

Input/Event Lankah Pengujian Output Output yang Seharusnya Hasil Pengujian Perencaanaan, isi Form, Klik Simpan Melihat Laporan Stok Login, Klik

Laporan EOQ Laporan EOQ

Laporan EOQ Sesuai Melihat Laporan Keluar Masuk Barang Login, Klik Laporan Keluar Masuk Barang Laporan Keluar Masuk Barang Laporan Keluar Masuk Barang Sesuai

Input Data User

Login, Klik User Management, Input Data User,

Klik Simpan Data User Tersimpan Data User Tersimpan Sesuai 4.2. Pembahasan

Dari hasil analisis data menggunakan autokorelasi dapat diketahui bahwa data penjualan keempat produk pupuk dari tahun 2010 sampai 2012 mempunyai pola tren yang berarti bahwa metode least square regression line cocok digunakan untuk memprediksi penjualan. Hal tersebut dikarenakan metode LSRL cenderung lebih akurat apabila data yang digunakan mempunyai pola tren. Hasil prediksi penjualan nantinya akan digunakan untuk menentukan kuantitas pemesanan optimal pada tahun tersebut. Hasil lainnya yang didapat adalah data tidak mempunyai pola musiman karena pada time lag 1 dan 12 koefisien korelasinya berbeda nyata dengan nol. Sedangkan hasil dari pengukuran keakuratan prediksi menunjukan bahwa ada kecenderungan nilai kesalahan rata-rata akan semakin meningkat apabila jumlah data yang diprediksi semakin besar.

Selain itu, hasil perhitungan biaya persediaan yang dikeluarkan oleh perusahaan pada tahun 2012 menunjukan bahwa jumlah persediaan mempengaruhi biaya penyimpanan dan biaya pengiriman. Oleh karena itu,

(36)

penentuan kuantitas optimum sangat dibutuhkan untuk mengurangi biaya persediaan yang terdiri dari biaya penyimpanan dan biaya pengiriman. Hasil analisis data juga menunjukan bahwa metode EOQ dapat menentukan kuantitas optimal sehingga dapat mengurangi biaya persediaan sebesar 20,27 % atau Rp 6.460.053,16. Dengan demikian, penerapan metode LSRL dan EOQ pada sistem pengendalian persediaan akan dapat menentukan kuantitas pemesanan optimum sehingga dapat mengurangi biaya persediaan.

Cara kerja aplikasi pengendalian persediaan yang dikembangkan pada penelitian ini yaitu dengan memprediksi jumlah permintaan pada tahun berikutnya dengan memanfaatkan data penjualan 3 tahun sebelumnya. Dari hasil prediksi kemudian dilakukan penentuan jumlah pemesanan yang optimal yang dapat menimalisir biaya pemesanan dan penyimpanan. Selain itu sistem juga dapat menentukan titik pemesanan ulang dan stok cadangan berdasarkan waktu tunggu dan jumlah permintaan atau penjualan. Hal tersebut juga yang menjadi pembeda penelitian ini dengan penelitian-penelitian sebelumnya.

Untuk menentukan kuantitas pemesanan optimal, titik pemesanan ulang dan stok cadangan aplikasi membutuhkan data penjualan minimal 2 tahun kebelakang sehingga jika ada produk baru yang belum mempunyai data penjualan minimal 2 tahun belum diproses oleh aplikasi. Data penjualan 2 tahun tersebut digunakan untuk memprediksi penjualan ditahun berikutnya.

Berdasarkan dari data penjualan yang telah diinputkan kedalam database, kuantitas pemesanan optimal untuk masing-masing produk yang dihasilkan oleh aplikasi sebanyak 1.448 zak untuk Bintang Sawit, 1.622 Zak untuk Niposca, 1.353

(37)

untuk Bioposka dan 2.338 botol untuk Grend Leaf dengan biaya pengiriman sebesar Rp. 15.000.000 dan biaya penyimpanan sebesar Rp. 4.200. Biaya penyimpanan tersebut didapat dari hasil rata-rata biaya penyimpanan keempat produk pupuk. Sedangkan titik pemesanan ulang dengan tingkat pelayanan 95 % dan waktu tunggu 2 minggu atau 0,5 bulan adalah 159 zak untuk Bintang Sawit, 189 zak untuk Niposca,133 zak untuk Bioposka dan 512 Botol untuk Grend Leaf. Dari hasil perhitungan tersebut pimpinan dapat menentukan kapan salah satu barang akan dipesan dan berapa banyak barang tersebut dipesan. Misalnya saja untuk produk Grend Leaf, pada saat jumlah persediaan produk tersebut sebesar 512 Botol perusahaan harus segera melakukan pemesanan sebanyak 2.338 Botol demikian juga dengan produk lainnya.

Besaran biaya pemesanan dan pengiriman dapat diatur oleh sekretaris sehinga biaya dapat menyesuaikan dengan kondisi yang sebenernya. Selain itu dengan aplikasi ini juga proses pencatatan persediaan dapat dilakukan secara kontinu tanpa memakan biaya yang mahal karena proses perhitungan dilakukan secara otomatis oleh aplikasi. Aplikasi juga dapat berjalan dengan baik ketika dilakukan uji coba pada web browser seperti mozila firefox. Dari hasil pengujian black box juga membuktikan sistem dapat berjalan sesuai tujuan pembuatan sistem. Link-link dan tombol berfungsi secara normal ketika dilakukan uji coba. Validasi inputan juga berfungsi dengan baik sehingga dapat mencegah kesalahan dalam pengimputan data.

Gambar

Tabel  4.1. Daftar Permasalahan
Tabel 4.2 Data Penjualan Pupuk
Tabel 4.3 Data Variabel A
Tabel 4.4 Data Variabel B
+7

Referensi

Dokumen terkait

Gambar 4 7 Tampilan program saat menampilkan hasil klasifikasi Pada gambar diatas menampilkan hasil klasifikasi dari hasil input data yang kemudian akan menghasilkan klasifikasi

Remaja yang tidak diberitahu atau tidak dipersiapkan dengan baik sejak awal tentang bagaimana cara menjaga kebersihan genitalia saat menstruasi, maka pengalaman akan

Jika pengecekan telah dilakukan maka bagian gudang melakukan pembaruan stok obat dengan mencatat jumlah barang yang masuk dan bagian gudang menyerahkan obat ke kasir sesaui

Melihat kondisi gudang yang tidak rapi dan kotor menunjukan bahwa gudang Sumber Sejahtera Pratama belum menerapkan 5S. Dari penataan barang hanya diletakan asal-asalan saja,

Persediaan alat tulis kantor dicatat pada aplikasi sistem persediaan 10 yang diterbitkan oleh Direktorat Jenderal Perbendaharaan, setiap barang yang keluar dari gudang harus

Nasabah yang akan melakukan gadai ulang hanya perlu membawa SBK asli serta membayar biaya sewa modal dan biaya administrasi. Namun untuk jenis kredit barang

Biaya BMHP akan masuk kedalam biaya direct tracing sedangkan biaya lainnya akan masuk dalam kategori biaya direct resources overhead HD merujuk pada perhitungan unit

Data tambah ikan masuk ke dalam database [√] Berhasil [ ] Gagal Kelola Pemesanan Penginapan Input update status Data tambah kategori dan kamar masuk ke dalam database