BAB III ANALISIS DAN PERANCANGAN
3.1 3.1.1
Analisis Sistem Analisis Masalah Pada saat ini masih ada perusahaan – perusahaan dagang yang menggunakan data dan
menghitung data secara manual dan prediksi subjektif saja. Perhitungan manual yang dilakukan adalah dengan melakukan pengamatan pada hasil penjualan sebelumnya dengan ditambahkan asumsi dan prediksi dari salesman yang bersangkutan. Asumsi dan prediksi tersebut merupakan hasil dari pengamatan mereka terhadap data yang ada dan hasil perbincangan dengan pelanggan untuk membantu mereka memberikan gambaran rencana pembelian berikutnya. Sehingga mereka harus menyediakan waktu lebih sering berkunjung dan menanyakan hal tersebut kepada pelanggan. Terkadang perhitungan dengan menggunakan asumsi membutuhkan banyak waktu bagi salesman untuk berpikir dan menebak berapa kira-kira penjualan yang akan terjadi di tahun depan. Tabel 3.1 adalah actual data hasil penjualan di tahun 2009 selama 12 bulan dari januari sampai desember. Tabel 3.1 Hasil Penjualan Tahun 2009 jan feb mar apr mei juni jul aug sept oct nov dec 1862 1579 1655 1655 1446 2274 1655 1909 1665 1636 1668 10250
Dari data penjualan di atas dan ditambah dengan hasil pembicaraan dengan para pelanggan, Salesman berasumsi bahwa penjualan di tahun 2010 akan meningkat dilihat dari penjualan di bulan desember. Kemudian didapatlah kisaran nilai penjualan di tahun 2010
44
45 yang diinput manual di dalam format excell untuk diberikan ke management seperti yang terlihat pada Tabel 3.2. Tabel 3.2 Hasil Estimasi Tahun 2010 Berdasarkan Asumsi jan feb mar apr mei juni jul aug sept oct nov dec 3000 3000 3000 3000 3500 3500 3500 2000 2000 2000 3000 6000
Akibat dari pembuatan anggaran secara manual dan subyektif tersebut membuat management berusaha mencari jalan keluar yang masih bisa dipertanggungjawabkan kebenarannya, seperti: 1. Apa saja data yang diperlukan sebagai masukan data yang merupakan parameter internal dan eksternal sehingga bisa menghasilkan keluaran yang diinginkan? 2. Algoritma apa yang bisa dipakai untuk bisa merumuskan hasil tersebut? 3. Kejelasan dalam membaca suatu keluaran informasi sehingga mudah dimengerti akan memberi kemudahan bagi para pengambil keputusan untuk menentukan anggaran yang akan datang. Bagaimana bentuk keluaran yang akan dihasilkan dari aplikasi ini?
3.1.2
Analisis Kebutuhan dan Sistem yang Diharapkan Kemudahan dalam proses pemasukan data dan perhitungan sehingga menghasilkan
data anggaran tahun depan yang diinginkan adalah hal yang diharapkan dari aplikasi yang akan dibuat. Sehingga diperlukan aplikasi yang memiliki alur proses yang mudah dan singkat untuk dilakukan oleh bagian administratif tersebut. Sehingga para salesman yang ada lebih ditekankan kemampuannya untuk mencapai target dan hasil penjualan yang tinggi. Untuk menjawab permasalahan diatas maka diperlukan suatu sistem yang bisa menghasilkan keluaran seperti yang diharapkan paling tidak bisa dipertanggungjawabkan. 1. Aplikasi yang akan digunakan adalah aplikasi berbasis web yang mudah untuk diakses.
46 2. Parameter yang digunakan sebagai masukan data adalah nilai penjualan di tahun sebelumnya yang merupakan suatu parameter internal dan eksternal mewakili daya beli pelanggan terhadap produk tersebut. Parameter eksternal lainnya yang juga bisa digunakan untuk masukan data adalah kuantiti akhir stok barang dan kebijakan manajemen mengenai jumlah prosentase stok yang disetujui untuk disimpan. 3. Algoritma yang akan digunakan untuk memproses masukan data tersebut adalah persamaan logistik yang merupakan salah satu persamaan yang terdapat pada Teori Chaos. 4. Hasil yang akan ditampilkan adalah berupa kisaran nilai estimasi untuk anggaran penjualan, pembelian dan stok barang di tahun yang akan datang. Alur sistem yang diharapkan bisa mengakomodasi hal tersebut bisa dilihat pada Gambar 3.1.
Gambar 3.1 Work Flow Sistem Prediksi Anggaran
1. Operator/admin melakukan proses pemasukan data berupa data penjualan tahun sebelumnya, nilai stok barang terakhir dan prosentase nilai yang diijinkan oleh manajemen untuk menyimpan jumlah barang. 2. Data yang masuk kemudian disimpan di database untuk bisa langsung segera diolah dan diproses proses perhitungannya menggunakan persamaan logistik. Prediksi nilai penjualan berikutnya termasuk dalam peramalan yang mengandung kerancuan, ketidakpastian, dan sebagainya. Untuk mengakomodasi ketidakpastian itulah digunakan
47 Teori Chaos atau teori sistem dinamik non linier untuk proses perhitungan dalam aplikasi ini. 3. Operator cukup dengan menekan tombol perhitungan maka proses perhitungan akan langsung otomatis dilakukan dan terlihat hasil untuk estimasi penjualan dari tahun yang sudah diinput sebelumnya. 4. Operator bisa menentukan sendiri berapa kisaran tahun yang ingin dilihat estimasi perkiraan anggaran untuk tahun-tahun yang akan datang. Penjelasan lebih jelas mengenai alur sistem pada Gambar 3.1 diatas adalah sebagai berikut: 1. Pada Tabel 3.3 menunjukkan data penjualan dari tahun 2004 – 2009 yang nantinya akan dimasukkan manual oleh operator. Nilai penjualan untuk masing-masing tahun tersebut bisa dilihat pada baris tahun yang ditunjukkan oleh angka 2004, 2005, 2006, 2007, 2008, dan 2009. Tabel 3.3 Data Penjualan Tahun 2004 - 2009
2. Selanjutnya proses perhitungan sudah bisa dimulai. Untuk bisa menggunakan rumus chaos yang akan di pakai di dalam sistem, hal pertama yang harus dilakukan adalah menentukan index tahun data, nilai max, dan nilai awal. Di atas baris kolom januari pada Tabel 3.3 merupakan data max dari setiap tahun di bulan yang sama. Pada baris t,
48 menunjukkan index dari urutan tahun tersebut dimulai dari yang paling tua ke yang paling muda. Nilai awal menggunakan nilai pertama pada data yang paling tua. 3. Pada Tabel 3.4 menunjukkan hasil perhitungan laju setiap penjualan yang ada menggunakan rumus malthus. Nilai laju terbaik akan digunakan dalam rumus chaos untuk menentukan nilai estimasi. Tabel 3.4 Hasil Perhitungan Laju Penjualan
Nilai tersebut bisa dilihat pada angka yang terletak di atas baris nama bulan pada Tabel 3.4 diatas. 4. Pada Tabel 3.5 menunjukkan hasil estimasi penjualan baik dari tahun sebelumnya yang digunakan sebagai data masukan dan juga prediksi untuk tahun yang akan datang. Hasil perhitungan tersebut merupakan implementasi dari rumus chaos untuk persamaan logistik. Tabel 3.5 Hasil Estimasi Penjualan Tahun 2004 - 2011
49 5. Pada Tabel 3.6 menunjukkan kesalahan relatif yang merupakan bentuk prosentase perbedaan antara data aktual dengan data hasil estimasi. Jika nilai prosentase kesalahan relatif paling kecil di tahun termuda, maka nilai laju yang digunakan sudah benar. Jika tidak maka proses perhitungan akan dimulai kembali dengan menggunakan nilai laju berikutnya untuk dicek nilai kesalahan relatifnya. Dari hasil kesalahan relatif paling kecil di tahun termuda maka kita sudah bisa mengambil hasil prediksi yang paling baik untuk digunakan. Tabel 3.6 Hasil Estimasi Penjualan Tahun 2004 - 2011
6. Pada Tabel 3.7 menunjukkan hasil keluaran dari sistem tersebut berupa anggaran penjualan, pembelian, dan stok barang. Dimana anggaran pembelian dan stok barang merupakan hasil dari perhitungan estimasi nilai penjualan dengan nilai stok barang terakhir dan jumlah prosentasi nilai dari barang yang boleh disimpan. Tabel 3.7 Anggaran Penjualan, Pembelian, dan Stok Barang 2010 - 2011
50
3.2
Perancangan Aplikasi Perancangan untuk aplikasi prediksi anggaran meliputi perancangan dengan UML,
basis data, dan antar muka. 3.2.1
Perancangan UML Perancangan sistem dalam penerapannya menggunakan UML yaitu use case diagram
dan user case skenario, activity diagram, class diagram, statechart diagram, sequence diagram, dan ERD. 3.2.1.1 Use Case Diagram Use case yang akan dibuat pada sistem prediksi anggaran terdiri dari menginput data dan memperoleh hasil seperti yang terlihat pada Gambar 3.2. Dan penjelasan dari use case tersebut bisa dilihat pada Tabel 3.8 dan Tabel 3.9 untuk setiap use casenya.
Gambar 3.2 Use Case Diagram Sistem Prediksi Anggaran
51 Tabel 3.8 Narasi use case menginput data Use case name Actor Brief Description Exception Basic Flow
Alternative Flow Pre-condition Post-condition
Menginput Data Operator Use case ini merupakan bagian dimana operator harus memasukkan data yang diperlukan sampai bisa menghasilkan laporan prediksi budget 1. Pilih Data – tekan Add data - ketik tahun dan data penjualan yang ada – tekan Insert Record 2. Tekan add parameter – ketikkan LastStock dan StockParam untuk jumlah stok terakhir dan kebijakan stok yang diperbolehkan – tekan Insert Parameter Pada Menu Data juga tersedia pilihan Edit dan Delete yang bisa dipilih sesuai kebutuhan Belum ada data yang tersimpan Data sudah tersimpan ke dalam database dan tampilan hasil data yang sudah dimasukkan langsung bisa ditampilkan
Tabel 3.9 Narasi use case memperoleh hasil Use case name Actor Brief Description
Exception Basic Flow
Alternative Flow Pre-condition Post-condition
Memperoleh Hasil Operator Use case ini merupakan bagian dimana ketika operator mengisi jumlah tahun yang akan diprediksi untuk dilihat dan menekan tombol generate velocity dan generate budget maka akan ditampilkan hasil prediksi berupa anggaran penjualan, pembelian, dan stok barang sejumlah tahun yang sudah ditentukan. 1. Pilih Calculation – tekan generate velocity 2. Pilih Budget – ketikkan jumlah tahun yang ingin dilihat prediksinya – tekan generate budget Hasil belum ada dan belum bisa ditampilkan Hasil estimasi perkiraan anggaran untuk tahun yang akan datang meliputi anggaran penjualan, anggaran pembelian, dan anggaran stok barang sudah bisa dilihat untuk digunakan.
3.2.1.2 Activity Diagram Gambar 3.3 menjelaskan tentang aktivitas yang dilakukan oleh user dan sistem dari awal belum adanya data sampai dengan menghasilkan keluaran data yang diinginkan. Dimulai dari user memasukkan data penjualan sebelumnya dan parameter eksternal lainnya kemudian oleh sistem disimpan di database dan dilakukan proses perhitungan. Jika data yang ada lebih dari 24 data (2 tahun) maka proses perhitungan dilakukan dengan membaca data secara vertikal dan jika kurang dari 2 tahun maka proses perhitungan dilakukan dengan membaca data secara horisontal. Hasil yang bisa dilihat oleh user adalah estimasi penjualan, pembelian dan stok barang.
52
Gambar 3.3 Activity Diagram Sistem Prediksi Anggaran
53 3.2.1.3 Class Diagram Gambar 3.4 menunjukkan class diagram pembuatan aplikasi prediksi anggaran. Terdapat 4 class yaitu class vars, class chaos, class small_chaos, dan class sales_data. Class vars dan class sales_data merupakan turunan dari class chaos. Sedangkan class small_chaos merupakan turunan dari class sales_data. Proses aplikasi ini dijalankan menggunakan fungsifungsi yang ada pada setiap class tersebut. Mulai dari fungsi memasukkan data, mengubah data, mengolah data, menghitung data, menghasilkan keluaran, dan penggunaan query itu sendiri.
Gambar 3.4 Class Diagram Sistem Prediksi Anggaran
3.2.1.4 StateChart Diagram Gambar 3.5 menunjukkan statechart diagram pembuatan aplikasi prediksi anggaran yang menggambarkan transisi dan perubahan keadaan dimulai saat aplikasi dibuka, saat memasukkan data dan parameter, mulai proses penghitungan, sampai hasil kisaran anggaran penjualan, pembelian, dan stok yang diinginkan tampil.
54
Gambar 3.5 StateChart Diagram Sistem Prediksi Anggaran
3.2.1.5 Sequence Diagram Gambar 3.6 menunjukkan sequence diagram pembuatan aplikasi prediksi anggaran yang menggambarkan skenario proses interaksi antar user dan sistem di dalamnya sehingga jelas urutan proses dan respon yang didapatkan dari interaksi tersebut. Dimulai dari user mengakses aplikasi, masuk ke dalam aplikasi, pemanggilan query, memasukkan data, data tersimpan di database, data diolah dan akhirnya menghasilkan tampilan kisaran anggaran yang diperlukan.
Gambar 3.6 Sequence Diagram Sistem Prediksi Anggaran
55 3.2.2
Desain Menggunakan Basis Data Struktur database pembuatan aplikasi prediksi anggaran dapat dilihat pada Gambar
3.7.
Gambar 3.7 ERD Sistem Prediksi Anggaran
Pada Gambar 3.7 terdapat 8 tabel. Tabel utama yang digunakan sebenarnya hanya ada 2 saja yaitu tabel sales data untuk menyimpan data penjualan dan tabel var untuk menyimpan nilai paramater exsternal. Sedangkan tabel lainnya yang akan digunakan dalam aplikasi tersebut hanyalah tabel sementara pada database yang diperlukan sebagai penempatan sementara dari hasil perhitungan untuk mengolah nilai-nilai yang dibutuhkan pada persamaan logistik dan memudahkan penulis dalam perancangan aplikasi ini. Untuk itulah tidak ada relasi yang terjadi antara tabel-tabel tersebut. Dikarenakan tabel tersebut bisa ada sebagai penempatan sementara dari hasil perhitungan alias berdiri sendiri sendiri. Tabel-tabel tersebut meliputi: 1. Tabel data_sales berfungsi untuk menyimpan data penjualan tiap tahun untuk 12 bulan. Terdiri atas 13 field tahun, m1, m2, m3, m4, m5, m6, m7, m8, m9, m10, m11, m12 dengan primary key : tahun.
56 2. Tabel var berfungsi untuk menyimpan nilai parameter lain yang bisa diubah ubah sewaktu waktu nilai variabelnya. Terdiri atas 2 field Param, Content. 3. Tabel laju berfungsi untuk menyimpan hasil perhitungan laju awal dari tiap penjualan. Terdiri atas 13 field tahun, m1 sampai dengan m12 dengan primary key : tahun. 4. Tabel best_laju berfungsi untuk menyimpan hasil perhitungan laju paling baik setiap bulannya yang akan digunakan untuk perhitungan chaos (laju akhir). Terdiri atas 13 field tahun, m1 sampai dengan m12 dengan primary key : tahun. 5. Tabel estimasi berfungsi untuk menyimpan hasil perhitungan perkiraan penjualan dengan menggunakan persamaan chaos untuk data-data yang sudah ada dalam tabel data_sales. Terdiri atas 13 field tahun, m1 sampai dengan m12 dengan primary key : tahun. 6. Tabel budget berfungsi untuk menyimpan hasil estimasi penjualan terbaik untuk perkiraan anggaran penjualan di tahun yang akan datang. Terdiri atas 13 field tahun, m1 sampai dengan m12 dengan primary key : tahun. 7. Tabel cp_data merupakan duplikat dari tabel sales data secara horizontal terdiri atas 5 field yaitu y, m, data, v, dan e dengan primary key : y dan m. 8. Tabel cp_bl merupakan table yang merupakan duplikat dari tabel best laju dengan 1 field yaitu bl.
3.2.3
Perancangan AntarMuka Ide dasar pembuatan aplikasi terdiri atas 3 menu utama yaitu menu data, menu
calculation dan menu budget. Proses memasukkan data termasuk perubahannya terdapat pada menu data. Proses perhitungan menggunakan persamaan chaos mulai dilakukan pada menu calculation. Proses penampilan hasil prediksi kisaran anggaran yang diinginkan terdapat pada menu Budget. Disain dasar sebagai gambaran awal dari aplikasi tersebut terlihat pada Gambar 3.8.
57
Gambar 3.8 Gambaran Pengembangan Sistem Prediksi Anggaran
Bentuk tampilan depan disain dari 3 menu utama tersebut tampak pada Gambar 3.9.
Gambar 3.9 Disain Halaman depan
1. Menu data yang juga adalah menu home merupakan menu dimana user bisa melakukan proses input, update dan delete untuk data penjualan dan parameter/variabel yang lain. Disain dari menu tersebut tampak pada Gambar 3.10.
Gambar 3.10 Disain form input data
2. Menu calculation merupakan menu dimana user bisa memulai proses perhitungan data yang sudah ada sehingga muncul tampilan tabel hasil laju, hasil estimasi penjualan, dan
58 hasil perhitungan kesalahan relatif dari data yang sudah ada. Disain dari menu tersebut tampak pada Gambar 3.11.
Gambar 3.11 Disain Tampilan Tabel Hasil Perhitungan
3. Menu budget merupakan menu dimana user bisa menentukan jumlah tahun yang akan diprediksi untuk kisaran estimasi anggaran penjualan, pembelian dan stok barang untuk tahun yang akan datang. Disain dari menu tersebut tampak pada Gambar 3.12.
Gambar 3.12 Disain Tampilan Tabel Perkiraan Anggaran Tahunan
