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.
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.
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 Penjualan Pupuk Bulan Tahun 2010 1.
Tahun 2011
Tahun 2012
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)
Penjualan Pupuk Bulan 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
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
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
3.
4.
Bioposka (Zak)
Grend Leaf (Botol)
Penjualan Pupuk Bulan 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 Sumber: Buku Pembelian dan Penjualan, Mitra Mandiri, 2013
843
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 (Yt − Ȳ)2
Bintang Sawit
Niposca
Bioposka
Grend Leaf
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
Tabel 4.4 Data Variabel B 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 − Ȳ
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
Variabel
Yt−7 − Ȳ
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 Autokorelasi
Time Lag
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
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.
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
1
1916
1864,167
51,83333
2686,694
2
2327
2430,667
-103,667
10746,78
3
3049
2997,167
51,83333
2686,694
1
1592
1603,833
-11,8333
140,0278
2
1920
1896,333
23,66667
560,1111
3
2177
2188,833
-11,8333
140,0278
1
5936
5684,167
251,8333
63420,03
2
5755
6258,667
-503,667
253680,1
3
7085
6833,167
251,8333
63420,03
2. Niposca
3. Bioposka
4. Grend Leaf
Dari hasil perhitungan kesalahan prediksi akan dihitung nilai kesalahan pangkat rata-rata pada hasil prediksi yang menggunakan metode LSRL. Nilai
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.
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 dokumendokumen 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.
Rincian biaya penyimpanan untuk masing-masing produk dapat dilihat pada tabel 4.9 Tabel 4.9 Rincian Biaya Penyimpanan Biaya Penyimpanan Bintang No
1
Jenis Biaya
Biaya Kesempatan (Opportunity Cost)
Niposca
Bioposka
Grend Leaf
(Rp/Zak/
(Rp/Zak/
(Rp/Zak/
(Rp/Botol/
Tahun)
Tahun)
Tahun)
Tahun)
3389,75
4283,75
4842,5
1117,5
Sawit
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
3964,23
4881,18
5805,35
2150,1
Total
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.
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
Tingkat
Penyimpanan Per
Persediaan
Unit (Rp)
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
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 Jumlah No
Pupuk
Penjualan (D)
Biaya Pemesanan/ Tahun (Rp) (Co)
Biaya
EOQ Qopt =
Penyimpanan/
𝟐𝑪𝒐 𝑫
Tahun (Rp) (Cc)
𝑪𝒄
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
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
31869648,83
25409595,67
6460053,16
Total
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
case diagram dari sistem baru dapat dilihat pada gambar 4.1
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.
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.
(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.
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 1. Use Case ini akan dimulai ketika bagian gudang memilih menu penerimaan barang.
Sistem
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. (5) Post Conditions
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.
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 User
Sistem
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. (2) Flow of Events
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 Pada akhir dari use case ini, admin akan dapat menambahkan data user.
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 Pada akhir dari use case ini, user akan dapat masuk ke dalam sistem.
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. (5) Post Conditions
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
Gambar 4.2 Component Diagram Barang
b. Component Diagram Barang Masuk
Gambar 4.3 Component Diagram Barang Masuk c. Component Diagram Barang Keluar
Gambar 4.4 Component Diagram Barang Keluar
d. Component Diagram User
Gambar 4.5 Component Diagram User e. Component Diagram Perencanaan
Gambar 4.6 Component Diagram Perencanaan
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.
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.
a.Tampilan Form Inputan Perencanaan Persediaan
Gambar 4.8 Inputan Perencaanaan Persediaan b. Tampilan Form Inputan Barang Masuk
Gambar 4.9 Inputan Barang Masuk
c. Tampilan Form Inputan Barang Keluar
Gambar 4.10 Inputan Barang Keluar d. Hasil Laporan Perencanaan persediaan
Gambar 4.11 Laporan Perencanaan Persediaan
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
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 Tambah Data Barang
Tambah Data Barang Masuk
Tambah Data Barang keluar
Melakukan Login Mengganti Password Mengimput Data Perencanaan
Lankah Pengujian Login, Klik Barang, Input Data Barang, Klik Daftar Login, Klik Barang Masuk, Input Data Barang Masuk, Klik Daftar Login, Klik Barang Keluar, Input Data Barang, Klik Daftar Mengimput username dan password Melakukan Login , mengganti password Login sebagai sekretaris, Klik
Output
Output yang Seharusnya
Hasil Pengujian
Data berhasil di simpan
Data berhasil di simpan
Sesuai
Data berhasil di simpan
Data berhasil di simpan
Sesuai
Data berhasil di simpan
Data berhasil di simpan
Sesuai
Memproses inputan
Memproses inputan
Sesuai
Password terganti
Password terganti
Sesuai
Data Tersimpan
Data Tersimpan
Sesuai
Input/Event
Lankah Pengujian Perencaanaan, isi Form, Klik Simpan
Output
Output yang Seharusnya
Hasil Pengujian
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,
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
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.
