## 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 kholid.haryono@uii.ac.id Fahmy Abida Asa Firdausi
Jurusan Informatika, Fakultas
Teknologi Industri, Universitas Islam Indonesia Jl. Kaliurang KM 14.5 Yogyakarta fahmyabida@gmail.com Hendrik Jurusan Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia
Jl. Kaliurang KM 14.5
Yogyakarta hendrik@uii.ac.id
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. P ENDAHULUAN
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 249.9 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..

## II. M ETODE
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 vi a 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
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  jual- beli 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 .

## 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
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.
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.

## 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  email  agar  dapat  membuka  status  validasi  dan sales dapat melakukan  perubahan.  Permintaan  perubahan  melalui  sms  atau  WA  tidak  diperkenankan  karena  susah dikelola  sedangkan  via  email  lebih  mudah  karena  terdokumentasi  dengan  baik  dan  jika  sewaktu-waktu terjadi komplain dapat digunakan sebagai bukti. Proses tersebut ditunjukkan pada Gambar 8

## Gambar 8. Skenario permintaan produk
2. Skenario pengambilan 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

## Gambar 9. Skenario pengambilan produk
3. 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

## Gambar 10. Skenario setoran penjualan
4. Skenario pelaporan kecurangan
Fitur pelaporan digunakan untuk mengendalikan sales dari praktik-praktik kecurangan yang mengakibatkan hilangnya  kepercayaan  pelanggan.  Melalui  akun  login  masing-masing  sales  dapat  melaporkan  rekan lainnya jika melakukan/dicurigai melakukan kecurangan. Laporan secara langsung dilihat oleh pemilik dan diubah statusnya menjadi „diproses‟. Setelah ada tindakan maka status akan diubah menjadi telah ditindak lanjuti. Kepastian setiap laporan ditindak lanjuti membuat sales pelapor lebih perduli terhadap perusahaan meskipun  belum  sampai  diberikan reward .  Data  yang  telah  masuk  dan  statistik  laporan  dan  tindakan kemudian  dijadikan  rujukan  membuat  aturan  terkait reward dan punishment mengenai  pelanggaran maupun bagi pelapor.
5. Antarmuka
Pada bagian ini ditunjukkan empat antarmuka utama terkait dengan skenario untuk menunjukkan gambaran proses yang terjadi.

## Gambar 11. Antarmuka permintaan produk
Form  dibagi  menjadi  dua  bagian.  Bagian  input  dan  daftar  transaksi.  Karena  ragam  produk  tidak  terlalu banyak, untuk mempermudah pengisian ditampilkan seluruh item baik yang akan dipesan maupun tidak. User hanyak mengisi jumlah yang dipesan maka  total  nilai  produk  yang diambil  akan muncul. Nilai ini penting sebagai gambaran total tagihan yang akan dibebankan kepadanya jika seluruh produk laku. Pada bagian  kanan  daftar  permintaan  terdapat  dua  tombol  yakni  validasi  dan  hapus.  Validasi  digunakan  oleh admin  sebagai  notifikasi  dan  pengunci  untuk sales bahwa  order  telah  diterima  dengan  jumlah  tertentu. Pengambilan produk ditunjukkan pada Gambar 12.
Gambar 12. Validasi pengambilan produk
Kolom  search  pada  Gambar  12  digunakan  untuk  melakukan  pencarian  data  dengan  kata  kunci  bebas.  Dapat dicari  per  tanggal,  nama sales maupun  angka-angka  yang  muncul  dan  status.  Disediakan  tiga  tombol  yakni Ambil, Edit, dan Hapus. Edit digunakan apabila ada permintaan lebih atau kurang dari sales dengan kondisi yang memungkinkan seperti stok masih tersedia atau ada stok sales lain yang dapat dialihkan berdasarkan kesepakatan dengan sales yang bersangkutan.
Setoran penjualan dan pengakuan tagihan ditunjukkan pada Gambar 13

## Gambar 13. Setoran penjualan
Ketika sales melakukan  setoran  disore  hari,  Ia  diberikan  informasi  mengenai  total  produk  yang  dibawa  dan mengisikan berapa yang terjual. Transaksi ini akan otomatis menghitung berapa stok yang terjual dan nilai yang ditagihkan.  Sebelumnya  diuji  cobakan sales hanya  menginput  sisanya  saja  karena  produk  sisa  dibawa  ketika melakukan setoran. Selisih nya saja yang diotomatis akan tetapi masukan dari sales lebih suka dan nyaman jika
jumlah  terjual  saja  yang  diisikan  sedangkan  sisanya  dihitung  otomatis.  Secara  sekilas  seolah  sama  akan  tetapi yang dirasakan oleh user berbeda.
Antar  muka  terakhir  yang  didemokan  adalah  pelaporan  dan  monitoring  laporan.  Antar  muka    ini  dapat ditunjukkan pada Gambar 14

## Gambar 14. Pelaporan kecurangan

## B. Pengujian perangkat lunak
Pengujian  sistem  digunakan  untuk  menguji  apakah  sistem  berhasil  melakukan  pengawasan  penjualan sales dan  memberikan  kemudahan  pengelolaan sales bagi  pemilik.  Pengujian  perangkat  lunak  dilakukan  dengan metode UAT ( User Acceptance Test )  [5] dan pengujian fungsional [6][7].
1) Pengujian Pengguna (User Acceptance Test)
Pengujian  ini  dilakukan  dengan  cara  wawancara.  Wawancara  dilakukan  dengan  4  sumber.  Sumber  pertama yaitu orang yang menggunakan sistem untuk melakukan pengawasan penjualan sales yaitu pemilik Super Dangsul, Bapak Syahrul. Tiga sumber berikutnya diambil secara acak dari orang yang dikenakan pengawasan oleh pemilik yaitu sales Super Dangsul.
Berdasarkan  wawancara  dengan  pemilik,  Ia  merasa  terbantu  dengan  adanya  sistem  monitoring. Pemilik  tidak lagi membutuhkan waktu lama dan prosedur berbelit untuk melihat dan menganalisis penjualan sales. Ia juga tidak lagi kesulitan apabila ada hutang setoran yang menumpuk. Semua penjualan sales tersimpan pada sistem sehingga pemilik lebih mudah melakukan monitoring.
Berdasarkan  wawancara  dengan sales ,  diperoleh  informasi  bahwa  mereka  merasa  terbantu  dengan  adanya aplikasi  ini. Sales tidak  perlu  melakukan  pemesanan  secara  langsung face  to  face dengan  pengepul. Sales dapat melakukan pemesanan tempe melalui aplikasinya. Hutang sales juga tercatat pada aplikasi sehingga memudahkan sales untuk mengingatkan hutang setoran. Selain itu, sales dapat melihat penjualan terdahulu untuk memudahkan dalam mempelajari riwayat penjualan.
Secara keseluruhan pihak UD. Super Dangsul merasa aplikasi telah berjalan sesuai dengan proses bisnis yang ada  dan  memudahkan  dalam  melakukan  monitoring  penjualan sales . Sales juga  merasa  lebih  mudah  untuk melakukan pemesanan produk dibanding sebelumnya.

## 2) Pengujian fungsionalitas
Pengujian  fungsionalitas  dilakukan  untuk  mengetahui  letak  kekurangan  sistem  dengan  memberikan  berbagai kasus  pengujian.  Pengujian  dilakukan  dengan  cara  memberikan  contoh  kasus  pengujian  kemudian  diujicobakan pada  sistem  untuk  mengetahui  kekurangan  sistem.  Pengujian  diujikan  pada  fungsi-fungsi  yang  ada  pada  sistem. Hasil pengujian dapat dilihat pada Tabel 2.

## TABEL 2. PENGUJIAN FUNGSIONAL
No Fungsi Persentase Keterangan 1. Login Dari 4 kasus yang diujikan, 4 diantarnya dinyatkakan berhasil. Persentase keberhasilan adalah 100% 4 kasus tersebut menguji validasi login dengan meng input kan sesuai kasus input an. 2. Manajemen Laporan Kecurangan Dari 2 kasus yang diujikan, 2 diantarnya dinyatakan berhasil. Prosentasi keberhasilan adalah 100% 2 kasus tersebut menguji verifikasi penghapusan laporan dan validasi laporan. 3. Manajemen Data Admin  Dari 7 kasus yang diujikan, 3 diantarnya dinyatakan berhasil. Prosentasi keberhasilan adalah 42.86% 7 kasus tersebut menguji penambahan, edit, dan hapus data admin. 4. Manajemen Data Sales Dari 13 kasus yang diujikan, 11 diantaranya dinyatakan berhasil. Prosentase keberhasilan adalah 84.61% 13 kasus tersebut menguji mengenai penambahan, edit, dan hapus data sales . 5. Cilil Hutang Dari 4 kasus yang diujikan, 4 diantaranya dinyatakan berhasil. Prosentase keberhasilan adalah 100% 4 kasus tersebut menguji input an cicilan hutang dan pelunasan hutang. 6. Manajemen Request Permintaan Tempe Dari 2 kasus yang diujikan, 2 diantaranya dinyatakan berhasil. Prosentase keberhasilan adalah 100% 2 kasus tersebut menguji penambahan dan penghapusan data request permintaan tempe. 7. Manajemen Permintaan Tempe Dari 2 kasus uji, 2 dinyatakan berhasil. Prosentase berhasil adalah 100% 2 kasus tersebut menguji validasi dan penghapusan data permintaan tempe. 8. Manajemen Pengambilan Tempe Dari 4 kasus yang diujikan, 4 diantaranya dinyatakan berhasil. Prosentase keberhasilan adalah 100% 4 kasus tersebut menguji validasi , verifikasi hapus dan edit data pengambilan tempe. 9. Setoran Hutang Dari 5 kasus yang diujikan, 5 diantaranya dinyatakan berhasil. Prosentase keberhasilan adalah 100% 5 kasus tersebut menguji
Dari  Tabel  2.  Pengujian  Fungsionalitas  ditemukan  bahwa  sistem  masih  memiliki  bug  minor  pada  beberapa form. Bug ini terdapat pada manajemen data admin dan manajemen data sales . Manajemen data admin memiliki bugs  pada  form  penambahan  dan  ubah  data  admin.  Sedangkan  manajemen  data sales memiliki  bugs  pada registrasi dan ubah data sales .
Pada  form  penambahan  dan  ubah  data  admin,  terdapat  bug  di  bagian  input username dan password .  Bug diperbaiki agar inputan username dan password tidak berisi karakter kosong. Sedangkan pada form penambahan dan ubah data sales , terdapat bug pada bagian inputan photo. Bug diperbaiki dengan memberikan validasi inputan pada photo agar inputan berupa file berekstensi jpg/png. Secara keseluruhan sistem sudah dapat digunakan untuk me-monitoring sales . Kekurangan (bug) yang ditemukan telah diperbaiki dan fungsi sistem sudah dapat berjalan sesuai dengan harapan

## IV. K ESIMPULAN
Kesimpulan  yang  dihasilkan  berdasarkan  penelitian  dan  pembahasan  sistem  informasi  monitoring  penjualan sales ditemukan  bahwa  (a)  berdasarkan  pengujian  UAT  dengan  teknik  wawancara  setelah  user  menggunakan sistem  menunjukkan  bahwa  sistem  dapat  memberikan  informasi  penjualan  yang  dapat  memberikan  kemudahan pemilik  untuk  melakukan  pengawasan  terhadap sales .  (b)  sistem  juga  terbukti  memberikan  kemudahan  bagi pemilik  dalam  melakukan  pengecekan  penjualan sales .  (c) sales mengakui  proses  pemesanan,  pengambilan, setoran, dan pembayaran hutang dirasa lebih terbuka dan dapat ditelusuri secara mandiri oleh sales. (d) pelaporan
kecurangan  dapat  menjaga  kredibilitas  perusahaan  dimata  pelanggan.  Pemilik  mendapat    kemudahan  dalam melakukan monitoring kepada okdum sales dari praktik kecurangan.

## U CAPAN T ERIMAKASIH
Terimakasih kepada Program Studi Informatika, Fakultas Teknologi Industri, Universitas Islam Indonesia yang telah memberikan dukungan dan fasilitas dalam pelaksanaan penelitian ini.
D AFTAR P USTAKA
[1]  Badan Standardisasi Nasional, “Tempe persembahan Indonesia untuk dunia,” bsn , 2012. [Online]. Available: http://www.bsn.go.id/uploads/download/Booklet_tempe-printed21.pdf. [Accessed: 15-Aug-2017].
[2]  KBBI, “Wiraniaga,” - . [Online]. Available: https://kbbi.web.id/wiraniaga. [Accessed: 15-Aug-2017].
[3]  R. S. Pressman, Software Engineering , Fifth. New York: Thomas Casson, 2001.
[4]  A. Dennis, B. H. Wixon, and R. M. Roth, System Analysis and Design , Fifth. New: Wiley & Sons, 2009.
[5]  C. Ku, N. Che, K. Mohd, and F. Shahbodin, “Personalized Learning Environment : Alpha Testing , Beta Testing & User Acceptance Test,” Procedia - Soc. Behav. Sci. , vol. 195, pp. 837–843, 2015.
[6]  I. Arsie, G. Betta, D. Capriglione, A. Pietrosanto, and P. Sommella, “Functional testing of measurement-based control systems : An application to automotive,” Measurement , vol. 54, pp. 222–233, 2014.
[7]  A. Grocevs, “The capabilities of automated functional testing of programming assignments,” in 2nd International Conference on Higher Education Advances , 2016, vol. 228, no. June, pp. 457–461.