(Studi kasus di UD. Super Dangsul)

Please download to get full document.

View again

of 13
29 views
PDF
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Sistem Informasi Monitoring Wiraniaga (Studi kasus di UD. Super Dangsul) Kholid Haryono Jurusan Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia Jl. Kaliurang KM 14.5 Yogyakarta
Document Share
Document Transcript
Sistem Informasi Monitoring Wiraniaga (Studi kasus di UD. Super Dangsul) Kholid Haryono Jurusan Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia Jl. Kaliurang KM 14.5 Yogyakarta Fahmy Abida Asa Firdausi Jurusan Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia Jl. Kaliurang KM 14.5 Yogyakarta Hendrik Jurusan Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia Jl. Kaliurang KM 14.5 Yogyakarta Abstrak UD. Super Dangsul merupakan pabrik tempe yang berdiri sejak tahun 1998 dengan karyawan sebanyak 20 orang dan sales 30 orang. Pabrik berlokasi di Yogyakarta ini mampu menghabiskan 1,2 ton kedelai untuk memproduksi. Sales adalah seseorang dibagian pemasaran dan merupakan pekerja lepas yang berada di luar lingkup pengawasan langsung dari pemilik. Seiring jumlah permintaan produk yang meningkat, dibutuhkan lebih banyak sales untuk mendistribusikan produk. Pada bagian pemasaran ini sering terjadi kecurangan yang dapat menimbulkan kerugian produksi. Kecurangan ini mengakibatkan perusahaan pernah mengalami kehilangan konsumen. Berdasarkan permasalahan yang ada maka peneliti mengusulkan sebuah sistem informasi yang dapat mempermudah pengelolaan dan pengawasan sales. Penelitian dimulai dari kajian pustaka, analisis kebutuhan, implementasi skenario, dan diuji menggunakan UAT (User Acceptance Testing) dan uji fungsional. Fungsi utama sistem telah dapat memberikan kemudahan pengelolaan sales. Sistem juga mampu melakukan monitoring aktifitas dan pengawasan terhadap sales dari kecurangan yang dapat mengakibatkan memburuknya nama baik perusahaan. Kata kunci sistem informasi; sistem monitoring; kecurangan transaksi; uji fungsional; UAT I. PENDAHULUAN Berdasarkan Badan Standar Nasional (BSN) tahun 2012 bahwa konsumsi tempe rata-rata per orang per tahun di Indonesia saat ini mencapai sekitar 6,45 kg [1]. Jika menggunakan data penduduk Indonesia tahun 2013 adalah juta jiwa, usia produktif makan tempe adalah 50% dari jumlah tersebut yakni 124 juta jiwa maka kebutuhan tempe mencapai 805,927,500 Kg per tahun. Kebutuhan sangat besar dan membutuhkan produsen yang dapat memenuhi permintaan. UD Super Dangsul adalah salah satu produsen tempe di provinsi D.I Yogyakarta. Perusahaan ini berdiri sejak tahun 1998 dan memiliki banyak pelanggan fanatik di wilayah DIY. Dalam sehari industri ini mampu menghabiskan 1,2 ton kedelai untuk keperluan produksi. Saat ini, produksi dan pemasaran dikerjakan oleh 20 orang karyawan bagian produksi dan 30 orang sales pemasaran. Sales merupakan pekerja lepas yang berada di luar lingkup pengawasan langsung dari pemilik. Sales lepas yang melakukan penjualan langsung kepada konsumen menurut Kamus Besar Bahasa Indonesia (KBBI daring) disebut juga wiraniaga [2]. Perusahaan menunjuk seorang staf yang bertindak selaku pengepul untuk mengelola sales. Untuk memenuhi permintaah yang terus meningkat, dibutuhkan banyak sales. Pengelolaan sales yang saat ini menggunakan pencatatan sederhana sering menimbulkan kesalah fahaman terutama pada proses pemesanan, pengambilan produk, dan setoran hasil distribusi. Pada bagian pemasaran ini juga sering terjadi kecurangan yang dapat menimbulkan kerugian perusahaan. Salah satu jenis kecurangan yang sering terjadi adalah permainan harga yang dilakukan oleh oknum sales padahal harga telah ditentukan oleh perusahaan. Mereka memanfaatkan tingginya permintaan sebagai kesempatan. Kecurangan ini mengakibatkan perusahaan pernah mengalami kehilangan beberapa konsumen setia. Belum ada mekanisme dan sistem yang mampu menangani jumlah sales dan praktik-praktik kecurangan secara baik. Berdasarkan permasalahan yang terjadi maka peneliti mengusulkan sistem informasi monitoring wiraniaga yang mampu mengelola dan melakukan pengawasan kepada seluruh sales agar reputasi perusahaan terus terjaga. Sistem ini diharapkan mampu membantu pemilik untuk dapat mengelola perusahaan semakin efektif dan efisien terutama untuk mengelola berapapun jumlah sales yang nantinya akan dipekerjakan. Kontribusi penelitian adalah pelajaran yang dapat dipetik dari temuan yang didapat pada setiap tahap pengembangan hingga implementasi.. J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 23 II. METODE Untuk menyelesaikan dua masalah utama penelitian ini, yakni pertama pengelolaan sales yang banyak dan cenderung meningkat, kedua memberikan kemudahan pengawasan terhadap sales dari praktik-praktik curang yang dapat menimbulkan hilangnya kepercayaan pelanggan, maka langkah-langkah yang dilakukan adalah: (a) wawancara kepada pemilik; (b) observasi untuk mengamati pengelolaan dilapangan; (c) pengumpulan dokumen operasional perusahaan; (d) tahapan perancangan sistem menggunakan general SDLC [3][4] yang dimulai tahap analisis kebutuhan, perancangan, implementasi, dan pengujian sistem. A. Wawancara pemilik Tahap ini paling penting untuk menentukan masalah utama yang dihadapi pemilik. Hal ini untuk menentukan spesifikasi kebutuhan dan harapan pemilik. Dari hasil wawancara, didapatkan dua hal penting yakni pertama meningkatnya animo masyarakat terhadap produk menuntut pemilik agar dapat meningkatkan jumlah sales. Pengelolaan sales sulit dilakukan karena mereka pekerja lepas yang kapan saja bisa keluar masuk. Dibutuhkan sistem yang dapat berkomunikasi secara otomatis pada setiap proses kerja sales mulai dari permintaan hingga setoran akhir. Pembukuan sederhana sering menimbulkan kesalahan terutama terkait dengan jumlah produk yang dipesan, jenis produk yang salah ambil, dan setoran yang kurang. Hal ini menimbulkan ketidaknyamanan sales, padahal mereka adalah ujung tombak dari perusahaan. Kedua terjadinya kecurangan yang dilakukan oleh oknum sales dengan memainkan harga ke konsumen. Akibatnya beberapa konsumen setia meninggalkan perusahaan dan beralih ke kompetitor. Pemilik membutuhkan sistem yang mampu mengawasi kinerja sales dalam hal kontrol terjadinya kecurangan. s B. Observasi Merupakan tahap melakukan pengamatan terhadap praktik yang sekarang terjadi. Pengamatan penting untuk melihat celah terjadinya persoalan. Berdasarkan pengamatan langsung yang dilakukan dengan menemani petugas pengepul dan pemilik setiap transaksi harian terjadi, proses yang terjadi adalah setiap hari sales memesan berbagai jenis produk berikut jumlahnya. Pesanan ini digunakan oleh pemilik untuk memprediksi jumlah yang diproduksi esok hari, pemesanan dilakukan dengan menulis pada buku besar dan masih bisa di ubah dengan mengirim pesan elektronik, titip pesan teman sales lain, atau via telpon. Pagi hari sales mengambil produk sesuai yang dipesan baik jumlah maupun jenisnya. Beberapa terjadi perselisihan karena perbedaan jumlah setiap jenis yang diambil, hal ini karena adanya perubahan pesanan yang dilakukan dan tidak tercatat secara rapi sehingga petugas yang mempersiapkan dipagi hari mengacu data pesanan yang berbeda. Sekaligus mengambil barang, sales juga memesan untuk esok harinya. Pada sore/malam hari, sales datang melaporkan setoran dan informasi sisa produk yang tidak laku. Perbedaan jumlah pengambilan, sisa yang disetorkan, dan produk yang diakui terjual kerap menimbulkan disharmoni antara perusahaan dan sales. Beberapa laporan pengaduan telah masuk melalui sales dan pelanggan kepada pemilik terutama terkait jumlah pesanan pelanggan kepada sales diantarnya kurang dari jumlah yang dipesan. Ada pelanggan yang lapor harga naik sampai dua kali lipat meskipun tidak ada kenaikan yang ditentukan oleh perusahaan. Ada sales yang mengirim produk lain kepada pelanggan. Beberapa temuan observasi ini menjadi masukan desain sistem yang dibutuhkan. C. Pengumpulan dokumen Dokumen operasional yang dilakuan dengan pembukuan sederhana dipelajari untuk memahami proses yang terjadi. Dokumen ini menunjukkan lemahnya pencatatan dan terkesan hanya formalitas karena sulit dibaca dan sering terjadi kesalahan baca dari petugas-petugas di lapangan. Dokumen ini meliputi catatan pemesanan, catatan produksi, dokumen pembayaran dan setoran, laporan harian, dan laporan kecurangan yang dilaporkan oleh sales dan pelanggan. Temuan pada tahap ini digunakan untuk mencari fitur sistem yang sesuai. D. Perancangan Berdasarkan general SDLC terdapat empat aktifitas utama yakni analisis kebutuhan, analisis desain, implementasi, dan pengujian sistem. Analisis kebutuhan dibagi menjadi empat yaitu analisis kebutuhan pengguna; analisis kebutuhan fungsional; analisis kebutuhan antarmuka; dan analisis kebutuhan desain. 1. Analisis kebutuhan pengguna Terdapat dua kebutuhan yang diidentifikasi yakni kebutuhan pengguna dan kebutuhan fungsional. Kebutuhan pengguna teridentifikasi tiga pihak yakni pengepul adalah seseorang yang berperan dalam mengelola permintaan, pengambilan dan setoran produk oleh sales. Kedua adalah pemilik, orang yang memiliki hak akses J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 24 penuh terhadap sistem website dan aplikasi monitoring. Ketiga adalah sales, seseorang yang berhubungan langsung dengan konsumen dan melakukan jual beli produk. 2. Kebutuhan Fungsional Pengepul secara fungsional melakukan aktifitas-aktifitas sebagai berikut: (a) melayani dan mem-validasi permintaan produk dari sales. (b) melayani pencatatan pengambilan penjualan sales. (c) melayani pencatatan setoran penjualan sales. (d) melakukan pengecekan dan rekap terhadap sales yang berhutang. Pemilik (Owner) secara fungsional melakukan beberapa aktifitas, yaitu (a) melakukan pengecekan penjualan. (b) melakukan pengecekan terhadap sales yang berhutang. (c) melakukan pengecekan laporan kecurangan oleh sales. (d) melakukan registrasi sales dan admin. Sales secara fungsional melakukan beberapa aktifitas, yaitu (a) melakukan permintaan produk kepada pengepul/admin. (b) melaporkan kecurangan yang dilakukan oleh oknum sales yang melanggar peraturan jualbeli dan berpotensi merugikan perusahaan dengan hilangnya kepercayaan pelanggan kepada perusahaan. 3. Kebutuhan Antarmuka Berdasarkan karakter transaksinya, terdapat dua kebutuhan antarmuka. Pertama, kebutuhan administratif dan monitoring umum menggunakan laptop (layar lebar). Aktifitasnya dapat dilakukan baik di meja administrasi maupun secara mobile (pemilik). Untuk karakter kebutuhan ini dibutuhkan antarmuka berbasis web yang dapat dibuka menggunakan layar lebar dan tidak terikat ruang dan waktu. Artinya dapat dilayani dimana saja dan kapan saja selama memiliki koneksi internet. Kedua kebutuhan pemesanan dan laporan sales yang mobile dan melekat pada gawai yang dipegang oleh sales. Sistem sales dibuat berbasis android. Basis android dipilih karena semua sales menggunakan gawai dengan sistem operasi ini. 4. Analisis desain Dalam perancangan sistem, metode yang digunakan adalah metode perancangan berorientasi objek dengan menggunakan UML (Unified Modeling Language). Bentuk UML yang digunakan adalah Usecase diagram dan activity diagram. Berdasarkan basis pengembangannya, usecase diagram yang dibuat ada dua yaitu diagram untuk sistem berbasis android dan diagram berbasis web. Untuk diagram berbasis android ditunjukkan pada Gambar 1, dan diagram berbasis web ditunjukkan pada Gambar 2. A. Usecase Diagram 1) Usecase Diagram basis Android Terdapat dua aktor pada Usecase sistem berbasis android yaitu sales dan pemilik. Aktor sales harus melakukan login untuk mengakses system. Proses-proses yang dapat dilakukan oleh sales adalah input permintaan produk, melihat setoran penjualan individu, dan input laporan kecurangan. Aktor pemilik juga harus melakukan login untuk melihat hasil penjualan produk seluruh sales. J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 25 Gambar 1. Usecase Diagram pada Android 2) Use Case Diagram basis Website Gambar 2. Usecase Diagram pada Website Terdapat dua aktor pada usecase sistem berbasis web, yakni aktor pengepul dan pemilik. Aktor pengepul dapat mem-validasi permintaan produk, mem-validasi pengambilan produk dan melakukan input pelunasan hutang. Aktor pemilik pada basis ini dapat melakukan validasi laporan kecurangan dan registrasi user admin dan sales. B. Activity Diagram Activity diagram digunakan untuk menjelaskan spesifikasi detail dari setiap use case diagram dengan menjelaskan alur aktivitas yang dilakukan oleh aktor dalam mengakses fungsionalitas pada sistem. Activity diagram untuk input permintaan produk ditunjukkan pada Gambar 3. Gambar 3. Activity Diagram Input Permintaan Produk Gambar 3 menjelaskan urutan proses yang dilakukan oleh sales ketika memesan permintaan produk. Dimulai dari sales membuka form permintaan, sistem menampilkan form, sales mengisi form sesuai dengan data yang diminta, dan terakhir menyimpan/submit pesanan dengan klik tombol submit. Pesanan ini akan masuk ke J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 26 dashboardnya pengepul. Selanjutnya pengepul melakukan validasi permintaan produk. Activity diagram validasi permintaan produk ditunjukkan pada Gambar 4. Gambar 4. Activity Diagram Validasi Permintaan Tempe Gambar 4 adalah proses pengepul melakukan validasi atas permintaan pesanan dari sales. Pengepul membuka detil pesanan sales dan mengubah status pesanan menjadi tervalidasi. Semua proses tersebut dilakukan satu hari sebelum produk diambil. Pada pagi hari, sales mengambil produk yang telah dipersiapkan oleh pengepul sesuai dengan pesanan hari sebelumnya. Activity diagram pengambilan produk ditunjukkan pada Gambar 5. Gambar 5. Activity Diagram Validasi Pengambilan Tempe Proses pengambilan produk pada Gambar 5 menunjukkan bahwa jumlah yang diambil dapat diedit sesuai dengan ketersediaan produk dan kebutuhan sales. Jika tidak ada perubahan makan proses hanya akan merubah status menjadi Ambil, sedangkan jika ada perubahan maka pengepul merubah jumlah yang diambil kemudian melakukan validasi. Setelah di-validasi, sales mengirimkan produk ke pemesan (end customer), ke pasar, atau warung-warung. Sore atau malam hari (sebelum pengambilan esok hari), sales harus melakukan setoran hasil penjualannya ke pengepul. Secara fisik yang dilakukan oleh sales adalah mengakui jumlah produk terjual, membayar sejumlah barang yang diakui terjual. Jika jumlah yang dibayar kurang dari seharusnya akan otomatis dicatat sebagai hutang sales. Dan terakhir mengembalikan sisa produk yang tidak laku. Activity diagram input setoran penjualan ditunjukkan pada Gambar 6. J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 27 Gambar 6. Activity Diagram Input Setoran Penjualan Setoran penjualan yang ditunjukkan pada Gambar 6 dimulai dari tampilan form setoran. Jika ada tagihan/hutang sebelumnya akan diinformasikan jumlah yang belum dibayar pada periode sebelumnya. Setoran yang diinput bukan jumlah rupiah akan tetapi jumlah item produk yang terjual, sistem akan otomatis menghitung jumlah rupiah yang ditagihkan. Pengepul memasukkan nilai uang yang diterima dan dimasukkan ke sistem. Jika jumlah kurang dari total tagihan akan dicatat sebagai tambahan hutang. Informasi tentang hutang pada proses ini sangat penting untuk mengendalikan hutang yang berlebihan. C. Perancangan Basis Data Perancangan basis data merupakan bagian dari proses pembangunan sistem. Basis data digunakan untuk menyimpan data dari sistem aplikasi monitoring wiraniaga. Struktur dan relasi tabel yang digunakan pada sistem ditunjukkan pada Gambar 7. Gambar 7. Struktur dan Relas Tabel Terdapat 9 tabel yang digunakan untuk mengolah proses-proses yang terjadi sehingga menjadi informasi yang dapat digunakan oleh pemilik perusahaan. Tabel-tabel tersebut diakses oleh aplikasi web dan mobile secara terpusat. Fungsi setiap tabel dan aplikasi yang mengakses ditunjukkan pada Tabel 1. J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 28 TABEL 1. DAFTAR TABEL DAN FUNGSINYA Nama tabel Deskripsi 1 Tempe Data master untuk menyimpan identitas produk 2 Sales_bawa_tempe Menyimpan data induk transaksi pengambilan produk berdasarkan order hari sebelumnya 3 Detail_sales_bawa_tempe Menyimpan item produk yang diambi. 4 Sales_setor_tempe Menyimpan data induk transaksi setor uang dari item produk yang terjual dan melaporkan sisa produk yang tidak laku 5 Detail_sales_setor_tempe Menyimpan data sisa produk yang telah diambil dan tidak laku. 6 Sales Menyimpan data master sales yang mencatat identitas. Data ini digunakan sebagai referensi dari tabel-tabel transaksi yang berelasi. 7 Kecurangan Menyimpan data laporan kecurangan dan status followup dari setiap laporan. 8 Hutang Menyimpan data kekurangan setoran. Misalnya jika total nilai produk laku adalah Rp 250,000 dan sales menyetorkan Rp 200,000 maka sistem secara otomatis mencatat selisihnya sebagai hutang. 9 Admin Tabel yang digunakan untuk menyimpan identitas karyawan berikut data login untuk mengamankan sistem dari campurtangan pihak luar. Tabel yang secara khusus digunakan untuk transaksi mobile adalah tabel Sales_bawa_tempe, Detail_sales_bawa_tempe, Sales_setor_tempe, dan Detail_sales_setor_tempe. Tabel tersebut menyimpan data transaksi utama yang akan diolah oleh sistem menjadi kontrol dalam pengelolaan inventori produk yang dikelola. III. IMPLEMENTASI DAN PENGUJIAN Implementasi sistem menjelaskan tentang hasil yang diperoleh dari tahapan sebelumnya, tahap perancangan sistem. Untuk mempermudah pembahasan, implementasi pengujian menggunakan teknik skenario sesuai dengan peran masing-masing user. Terdapat empat skenario (1) skenario permintaan produk, (2) skenario pengambilan produk, (3) skenario setoran penjualan, dan (4) skenario pelaporan kecurangan. A. Implementasi 1. Skenario Permintaan Produk Menunjukkan arus permintaan yang dilakukan oleh sales menggunakan aplikasi mobile dengan gawai. Proses dimulai dari input pemesanan produk, sistem menyimpan ke database dengan status belum valid, admin melakukan validasi pemesanan dan mengirimkan notifikasi validasi kepada sales bahwa pesanan telah divalidasi sehingga sales dapat memantau apakah order sudah diterima atau belum. Perubahan jumlah dan item produk yang diorder tidak boleh diganti setelah admin melakukan validasi. Jika terpaksa ada perubahan, sales menghubungi admin via agar dapat membuka status validasi dan sales dapat melakukan perubahan. Permintaan perubahan melalui sms atau WA tidak diperkenankan karena susah dikelola sedangkan via lebih mudah karena terdokumentasi dengan baik dan jika sewaktu-waktu terjadi komplain dapat digunakan sebagai bukti. Proses tersebut ditunjukkan pada Gambar 8 J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 29 2. Skenario pengambilan produk Gambar 8. Skenario permintaan produk Pengambilan produk dilakukan setiap pagi. Petugas mempersiapkan produk yang telah dikelompokkan berdasarkan pesanan sales yang telah divalidasi. Sales mengambil produk berdasarkan jenis dan jumlah yang dipesan. Admin melakukan pengecekan saat proses pengambilan dan mengubah status validasi menjadi status ambil untuk produk yang telah keluar. Sales dapat notifikasi bahwa pesanan telah diambil. Notifikasi digunakan untuk memastikan sekaligus verifikasi bahwa jumlah yang diambil sesuai dengan order yang telah divalidasi sebelumnya. Skenario tersebut ditunjukkan pada Gambar 9 3. Skenario pengambilan produk Gambar 9. Skenario pengambilan produk Proses ini dilakukan setiap sore/malam hari setelah sales mendistribusikan produknya. Sales melaporkan berapa yang terjual dan mengembalikan sisa produk. Jumlah sisa dan terjual harus sama dengan jumlah pengambilan. Jumlah yang harus disetor adalah selisih antara produk yang diambil dan dikembalikan menjadi tagihan pembayaran bagi sales. Pembayaran dapat dilakukan kurang dari yang ditagihkan dan akan masuk pos hutang setiap sales. Hutang bisa dibayarkan bertahap sesuai kemampuan. Mekanisme ini dilakukan untuk menjaga kepercayaan dan loyalitas sales kepada perusahaan. Skenario setoran ditunjukkan pada Gambar 10 J u r n a l M a s y a r a k a t I n f o r m a t i k a U n j a n i H a l a m a n 30 4. Skenario pelapora
Similar documents
View more...
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks