RANCANG BANGUN APLIKASI APOTEK (Studi Kasus: Ashara Husada Sidoarjo) Nicko Happy Atmaja 1) Dewiyani Sunarto 2) Ayuningtyas 3) Program Studi/Jurusan Sistem Informasi Institut Bisnis dan Informatika Stikom Surabaya Jl. Raya Kedung Baruk 98 Surabaya, 60298 Email : 1) nickohappy7@gmail.com, 2)dewiyani@stikom.edu, 3)tyas@stikom.edu Abstract Ashara Husada pharmacy in cooperation with health foundation of PT.Telkom Indonesia. This health foundation formed to serve needs of health for the employees, retired employees, and their families those residing in Sidoarjo and the surrounding areas. Ashara Husada Clinics and pharmacies are not only serve the employees, retired employees, and families, but also commit services for the public, which there are currently have difficulty processes to running it. The difficulty lies in the supply of medicines which are always in shortage supply, as well as the lack of information available medicine stocks. The idea design of pharmacy application on ashara husada pharmacy are takes part to commit the transaction records, handle the shortages and overage of medicine stock, as well as displaying a graph of purchase, sale and rejection of medicine sales. With this pharmacy application, can assist the pharmacist in purchasing of medicines up to print the transaction report. After the trialled, the pharmacy application at ashara Husada pharmacy can record the medicine transaction. So this application can 1) records the medicine transactions, 2) handle the shortage and overage stock of medicines with ROP calculations, 3) Displaying a graph of sales, purchasing, stock and rejection of medicine sales. Keywords: Recording of Transactions,Reorder Point (ROP), Pharmacy Klinik dan apotek Ashara Husada terletak di Ruko Jati Kepuh Indah Blok C7, Jl. Larangan, Sidoarjo. Ashara Husada bekerja sama dengan yasan Kesehatan (YAKES) PT. Telkom Indonesia. yasan Kesehatan ini merupakan yayasan yang dibentuk untuk melayani pemenuhan kebutuhan kesehatan bagi pegawai, pensiunan, serta keluarga yang menjadi tanggungan pegawai PT. Telkom Indonesia yang berdomisili di Sidoarjo dan sekitarnya. Klinik dan apotek Ashara Husada tidak hanya melayani pegawai, pensiunan, dan keluarga PT. Telkom Indonesia saja, namun juga melakukan pelayanan kesehatan bagi masyarakat umum. Prosedur pada apotek Ashara Husada dalam penjualan mengutamakan pelayanan pada pegawai, pensiunan, dan keluarga PT. Telkom Indonesia karena klinik dan apotek Ashara Husada memiliki kerja sama dengan yasan Kesehatan (YAKES) PT. Telkom Indonesia. Permasalahan timbul ketika apoteker saat akan melakukan penjualan tetapi yang akan dibeli pasien tidak tersedia atau kehabisan stok, maka pasien harus melakukan pemesanan. Hal ini disebabkan oleh stok selalu mengalami kekurangan stok sehingga mengakibatkan pasien harus menunggu 3 hari untuk tersedia kembali, pada proses pengadaan apoteker tidak mampu menentukan jumlah pembelian setiap, serta tidak adanya catatan baku mengenai jumlah yang dibeli dan yang terjual. Bila hal tersebut tidak diambil tindakan maka beresiko kepada berkurangnya kepercayaan masyarakat kepada JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 1
apotek bahwa apotek dinilai tidak mampu menyediakan pelayanan kesehatan masyarakat serta pemutusan kerja sama denga pihak yayasan kesehatan PT. Telkom. Bila tidak tersedia maka pihak apotek akan mencatat tersebut dan berusaha melakukan pembelian dengan segera untuk pasien pegawai, pensiunan dan keluarga PT. Telkom dengan jumlah penolakan rata-rata 5% dari transaksi penjualan setiap bulan. Namun untuk masyarakat umum, dalam penjualan kurang diprioritaskan karena bila tidak tersedia maka pasien umum dapat membeli di apotek lain. Sedangkan untuk penolakan layanan penjualan bagi pasien umum hanya dilakukan secara lisan tanpa ada catatan apapun. Pada proses retur dari pasien, pihak apotek akan menerima dan menanyakan alasan tersebut dikembalikan. Biasanya pasien mengembalikan karena pasien tersebut mengalami alergi terhadap pemakaian tertentu dan pihak apotek memberikan catatan tertentu terhadap pasien tersebut, tetapi pihak apotek tidak memberikan ganti rugi yang diretur oleh pasien. Pihak apotek dalam melakukan pembelian memastikan yang dibeli memiliki tanggal kadaluarsa lebih dari 1 tahun. Jika pada saat memesan ke pihak suplier dan yang dipesan apotek memiliki tanggal kadaluarsa kurang dari 1 tahun, maka suplier tersebut akan menginformasikan bahwa tersebut akan kadaluarsa dan pihak apotek tidak memesan tersebut kepada suplier tersebut dan memesan ke suplier lain. Dalam pencatatan seluruh data transaksi pembelian, pembelian, dan pesanan pasien YAKES dilakukan secara manual dan menggunakan dokumen konvensional yang rawan rusak dan hilang. Dengan metode pencatatan yang demikian, keakuratan data sangat diragukan karena sulitnya melakukan pengecekan transaksi penjualan, pembelian, pesanan, retur, dan penanganan kadaluarsa pasien YAKES dengan dokumen-dokumen yang ada. Dokumendokumen yang sebelumnya adalah berupa tabel excel, buku, catatan kecil untuk persediaan. Akibatnya tidak dapat diketahui apabila ada transaksi yang tidak tercatat atau stok yang tidak diketahui jumlahnya akibat tidak akuratnya dokumen-dokumen tersebut. Sehingga pelayanan terhadap penyediaan menjadi menurun. Bila kondisi ini dibiarkan, dapat berakibat pihak PT. Telkom akan mencabut kerja sama dengan pihak klinik dan apotek tersebut. Pada penelitian sebelumnya yang dilakukan oleh Ontowiryo (2012) pada klinik Ashara Husada membahas tentang pendapatan klinik Ashara Husada meliputi pelayanan kesehatan seperti pemeriksaan pasien, pelayanan laboratorium, dan transaksi penjualan. Penelitian tersebut bertujuan untuk membantu pihak klinik untuk mencatat transaksi pelayanan kesehatan guna menghasilkan rekap klaim pelayanan kesehatan yang akan diberikan kepada YAKES PT. Telkom, serta rekap transaksi pelayanan kesehatan pasien umum. Sedangkan pada penelitian ini hanya membahas transaksi penjualan, pembelian, retur, JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 2
penanganan kadaluarsa dan penolakan pelayanan penjualan. Untuk mengatasi permasalahan pada apotek Ashara Husada diperlukan sebuah aplikasi pencatatan transaksi penjualan dan pembelian yang dapat membantu bagian apoteker dalam melaksanakan tugasnya untuk melakukan pencatatan transaksi penjualan, pembelian, retur dan penanganan kadaluarsa guna menghasilkan laporan pelayanan transaksi pasien YAKES PT. Telkom Indonesia dan pasien umum. METODE Tahapan SDLC Kebutuhan perangkat lunak dapat diartikan sebagai properti yang harus dipamerkan dalam rangka memecahkan beberapa masalah di dunia nyata (Alfarisyi, 2014). Model incremental melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem perangkat lunak yaitu tahap communication, planning, modeling, construction dan deployment Berikut ini adalah penjelasan dari tahap-tahap yang dilakukan di dalam model waterfall: 1. Communication (komunikasi) Langkah ini merupakan analisis terhadap kebutuhan software, dan tahap untuk mengadakan pengumpulan data dengan melakukan pertemuan dengan customer, maupun mengumpulkan data-data tambahan baik yang ada di jurnal, artikel, maupun dari internet. 2. Planning (perencanaan) Proses planning merupakan lanjutan dari proses communication (analysis requirement). Tahapan ini menggambarkan tugas-tugas teknis yang dilakukan, sumber daya yang dibutuhkan, produk yang harus dihasilkan, dan jadwal-jadwal kerja termasuk rencana yang akan dilakukan. 3. Modeling (pemodelan) Proses modeling ini akan menerjemahkan syarat kebutuhan-kebutuhan menjadi sebuah perancangan software yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada rancangan struktural data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Pada aplikasi apotek ini menggunakan perhitungan Reorder Point System(ROP). Dalam sistem ROP setiap pusat distribusi pada tingkat lebih rendah (store or branch warehouse) meramalkan permintaan untuk produk guna melayani pelanggannya, kemudian memesan dari pusat distribusi pada tingkat lebih tinggi (main warehouse) apabila kuantitas dalam stok pada pusat distribusi yang lebih rendah (branch warehouse) mencapai ROP (Gaspersz, 2004). ROP diterapkan untuk setiap stockkeeping unit (sku) sebagai ramalan permintaan selama waktu tunggu pengisian (panjang waktu tunggu untuk resupply dari wholesale, atau area atau warehouse ditambah stok pengaman). ROP dan stok pengaman ditentukan secara konvensional. Sistem ini dapat menghasilkan permintaan yang sangat bervariasi di pusat distribusi pada tingkat yang lebih tinggi (central warehouse) karena hanya JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 3
memiliki interaksi yang kecil atau sedikit di antara branch warehouse dan central warehouse, sehingga membutuhkan stok pengaman yang relative besar pada central warehouse di samping stok pengaman pada branch warehouse. Pada proses pengadaan terdapat perhitungan ReOrder Point(ROP) yang berguna untuk menentukan pada jumlah berapa harus melakukan pengadaan kembali. Gambar di bawah ini merupakan flowchart perhitungan dari ROP. mulai - Int ROP, DLT, SS, inventori DLT ROP = DLT + SS ROP selesai Gambar 1 Gambar Flowchart Perhitungan ReOrder Point ROP = DLT + SS ROP = Titik Pemesanan Kembali (Reorder Point) DLT = Permintaan Selama Waktu Tunggu (Demand During Lead Time ) SS = Stok Pengaman (Safety Stock) Untuk contoh perhitungan dari metode ROP ini kita mengambil contoh data pembelian dan penjualan pada bulan Maret 2014. Misalnya kita akan menghitung Cardivask. Pada data persediaan terdapat 390 tablet namun terdapat permintaan sampai 450 sehingga permintaan yang belum tercukupi sebanyak 60 tablet dan diketahui stok pengaman sebanyak 20 buah, maka perhitungan ROP untuk Cardivask sebagai berikut DLT = total permintaan persediaan = 450 390 = 60 Tablet SS = 20 Tablet ROP = DLT + SS (10) ROP = 60 tablet + 20 tablet ROP = 80 tablet 4. Construction (konstruksi) Construction merupakan proses membuat kode. Coding atau pengkodean merupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu software, artinya penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap perangkat lunak yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap perangkat lunak tersebut untuk kemudian bisa diperbaiki. 5. Deplyoment (pengoperasian) Tahapan ini bisa dikatakan akhir dalam pembuatan sebuah software atau sistem. Setelah melakukan analisis, desain dan pengkodean maka sistem perangkat lunak yang sudah jadi akan digunakan oleh user. Kemudian software yang telah dibuat harus dilakukan pemeliharaan secara berkala. JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 4
Analisis Dan Perancangan Sistem Pembelian Aliran Sistem Proses Pembelian Supplier Pada aliran system proses pembelian Data Data penolakan penjualan proses diawali dengan sistem terlebih dahulu membaca data dari tabel data, data Penjualan Hitung ROP ROP Pesanan penolakan transaksi penjualan, penjualan, dan pemesanan untuk menentukan ReOrder System(ROP) di mana ROP ini berfungsi untuk menentukan jumlah yang harus melakukan Pilih yang akan dibeli Simpan ROP Simpan ROP Jumlah pengadaan ROP Simpan Surat Pemesanan Data pembelian Cetak Surat Pemesanan Surat Pemesanan Surat Pemesanan pembelian kembali. Setelah ROP diperoleh maka Kadaluarsa? akan muncul apa saja yang harus dilakukan Melakukan pembayaran Menyerahkan pembelian, memasukkan jumlah yang akan dipesan yang kemudian data tersebut disimpan ke Data pembelian Simpan transaksi pengadaan Pembayaran Membuat bukti pembayaran Bukti pembayaran dalam tabel penjualan. Setelah itu pihak pembelian Data apoteker mencetak surat pemesanan dan Perbarui data Update stok kemudian memberikan kepada pihak supplier. Setelah supplier menerima surat pemesanan, Data supplier melakukan pengecekan apakah yang dipesan mendekati kadaluarsa atau tidak, bila telah mendekati kadaluarsa maka supplier memberikan informasi bahwa yang dipesan akan kadaluarsa dan apoteker dapat memesan ke supplier lain. Jika tidak, supplier memberikan dan apoteker melakukan pembayaran. Kemudian apoteker menyimpan transaksi pembelian tersebut pada tabel transaksi pembelian. Kemudian apoteker memperbarui data pada tabel stok. Gambar 3 Aliran Sistem Proses Pembelian Aliran Sistem Proses Penjualan Pada aliran sistem proses penjualan proses diawali dengan proses pengecekan persediaan, jika tersedia apakah pasien merupakan pasien pegawai, pensiunan atau termasuk keluarga PT. Telkom atau pasien umum. Jika termasuk pasien pegawai PT. Telkom maka apoteker langsung menyimpan data penjualan pasien PT. Telkom. Jika pasien umum, apoteker menghitung total harga yang dibayar oleh pasien yang kemudian menyimpan data penjualan tersebut ke dalam tabel transaksi penjualan. Jika tidak tersedia, maka pasien dapat memesan tersebut. Ketidaktersediaan dikarenakan yang dipesan biasanya tidak terdaftar pada Daftar Telkom, sehingga pasien harus memesan terlebih dahulu. JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 5
Jika pasien bersedia memesan dan menunggu, maka apoteker memasukkan data dan data pasien dan menyimpan data tersebut ke dalam tabel pemesanan. Kemudian mencetak data tersebut yang kemudian diberikan kepada pasien. Bila pasien tidak bersedia memesan dan menunggu maka pasien dapat membeli pada apotek lain, namun apoteker akan mencatat penolakan penjualan pada proses penolakan penjualan. Penolakan Penjualan 1 Simpan data yang tidak terlayani Data penolakan transaksi penjualan Pasien Penjualan Pasien 2 Pasien Data Cek persediaan Gambar 5 Aliran Sistem Proses Penolakan Penjualan. Aliran Sistem Proses Menampilkan Kadaluarsa Pada aliran sistem proses menampilkan kadaluarsa ini sistem akan membaca tabel Pembayaran Nota Penjualan Hitung Total Total pembayaran Penjualan Pegawai Telkom Data Tersedia? Simpan Penjualan Data Penjualan pasien Cetak Nota Penjualan Simpan pesanan Menunggu 1 transaksi pembelian, stok yang kemudian sistem akan melakukan pengecekan tanggal kadaluarsa. Kemudian data yang kadaluarsa akan muncul. 1 Nota Penjualan Copy resep Pesanan Cetak Pesanan Kadaluarsa Pesanan Pesanan 1 Gambar 4 Aliran Sistem Proses Penjualan Pembelian Data Cek tanggal kadaluarsa Aliran Sistem Proses Penolakan Penjualan Pada proses aliran sistem ini merupakan lanjutan dari aliran sistem penjualan. Proses ini diawali dengan proses memasukkan data yang terdapat pada resep dan menyimpan data tersebut pada tabel penolakan transaksi penjualan. Kemudian resep diberikan kembali kepada pasien. Kadaluarsa? Data kadaluarsa cetak kadaluarsa Gambar 6 Aliran Sistem Proses Menampilkan Kadaluarsa JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 6
Aliran Sistem Proses Retur Pada aliran sistem proses retur, pasien Menampilkan Data memberikan yang diretur. Setelah itu Data apoteker memasukkan data yang diretur, Pilih Menu penjualan Data Penolakan penjualan kemudian sistem menampilkan data transaksi Menampilkan Data Pesanan penjualan, kemudian apoteker memasukkan data keluhan pasien ke dalam tabel pasien dan Data yang terjual Data yang terpenuhi dan tidak perbulan Data yang sering dicari perbulan Stok disimpan. yang diterima apoteker selanjutna Cetak data akan disimpan namun tidak dijual kembali dan biasanya untuk dihancurkan atau dikembalikan Data yang terjual Data yang terpenuhi dan tidak Data yang sering sering dicari Stok kepada supplier. Retur Pasien Gambar 8 Aliran Sistem Proses Menampilkan Data Data retur pasien Tampilkan data Penjualan Tampilkan Form Retur Penjualan Form Retur Keterangan Keluhan Simpan data penjualan? Retur 2 Gambar 7 Aliran Sistem Proses Retur Aliran Sistem Proses Menampilkan Data Pada aliran proses menampilkan data, apoteker memilih menu terlebih dahulu untuk menampilkan data yang ingin ditampilkan, data yang ditampilkan tersebut dapat dicetak. Berikut gambar aliran sistem proses menampilkan data. Gambar 9 Context Diagram JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 7
Model Data Konseptual rop rop_id <pi> Serial periode Date ss Integer apoteker total_permintaan Integer bentuk_ stok Integer apoteker_id <pi> Serial user adalah karyawan user rop Integer bentuk id <pi> Serial nik Variable characters (25) nama Variable characters (255) user_id <pi> Serial bentuk Variable characters (100) rop_pk <pi> no_ktp Variable characters (20) username Variable characters (255) bentuk pk <pi> hire_date Date password Variable characters (255) apoteker_pk <pi> user_pk <pi> penggunaan perhitungan rop _id <pi> Serial noreg Variable characters (25) apa saja yang diretur nama Variable characters (100) penolakan tanggal_kadaluarsa Date penolakan_id <pi> Serial stok_total Integer no_penolakan Integer _pk <pi> tanggal_penolakan Date & Time penolakan_pk <pi> menjual melakukan pembelian butir dengan menggunakan perhitungan ROP. Sistem menangani kekurangan dengan menampilkan warning dan bila menekan button OK pada warning tersebut maka akan langsung muncul form pemesanan. Hasil uji coba dapat dilihat pada gambar 13 dan 14. penjualan yang tertolak penjualan penjualan_id <pi> Serial no_penjualan Variable characters (25) tanggal_penjualan Date & Time penjualan_pk <pi> melakukan pemesanan retur penjualan yang diretur retur_id <pi> Serial no_retur Variable characters (25) tanggal_retur Date & Time retur_pk <pi> pengadaan ada yang dari pemesanan ada yang tidak pembelian pesanan pembelian_id <pi> Serial pesanan_id <pi> Serial no_pembelian Variable characters (25) no_pesanan Variable characters (25) tanggal_pembelian Date & Time tanggal_pesanan Date & Time pembelian_pk <pi> pesanan_pk <pi> Memesan_ penjualan ke pasien pasien pasien_id <pi> Serial kode Variable characters (50) nama Variable characters (255) no_ktp Variable characters (20) pasien_pk <pi> retur oleh pasien jenis pasien jenis_pasien jenis_pasien_id <pi> Serial jenis_pasien Variable characters (50) jenis_pasien_pk <pi> Gambar 11 ERD CDM apoteker apoteker_id <pk> nik varchar(25) rop nama varchar(255) no_ktp varchar(20) rop_id <pk> _id <fk> bentuk_ hire_date date periode date bentuk id <pk> ss bentuk varchar(100) total_permintaan FK_USER_USER_ADAL_APOTEKER stok rop user FK_ROP_PERHITUNG_OBAT user_id <pk> FK_OBAT_PENGGUNAA_BENTUK_O apoteker_id <fk> username varchar(255) password varchar(255) _id <pk> bentuk id <fk1> penjualan_id <fk2> noreg varchar(25) FK_PEMBELIA_MELAKUKAN_OBAT FK_OBAT_MENJUAL_PENJUALA nama varchar(100) tanggal_kadaluarsa date stok_total FK_RETUR_OBAT_APA OBAT retur retur_id <pk> pas_pasien_id <fk2> pen_penjualan_id <fk1> FK_RETUR_PENJUALAN_PENJUALA _id <fk3> FK_PESANAN_MELAKUKAN_OBAT no_retur varchar(25) penjualan tanggal_retur timestamp penjualan_id <pk> pas_pasien_id <fk> no_penjualan varchar(25) tanggal_penjualan timestamp pembelian pesanan FK_PEMBELIA_PENGADAAN_PESANAN pembelian_id <pk> pesanan_id <pk> pes_pesanan_id <fk1> _id <fk1> _id <fk2> pas_pasien_id <fk2> FK_PENOLAKA_PENJUALAN_PENJUALA no_pembelian varchar(25) no_pesanan varchar(25) tanggal_pembelian timestamp tanggal_pesanan timestamp penolakan FK_PESANAN_MEMESAN_O_PASIEN penolakan_id <pk> penjualan_id <fk> no_penolakan tanggal_penolakan timestamp pasien pasien_id <pk> jen_jenis_pasien_id <fk> FK_RETUR_RETUR_OBA_PASIEN kode varchar(50) FK_PENJUALA_PENJUALAN_PASIEN nama varchar(255) no_ktp varchar(20) FK_PASIEN_JENIS_PAS_JENIS_PA jenis_pasien jenis_pasien_id <pk> jenis_pasien varchar(50) Gambar 12 ERD PDM HASIL DAN PEMBAHASAN Pada uji coba menunjukkan bahwa sistem dapat menangani kekurangan stok ketika telah mencapai di bawah stok aman yaitu 20 Gambar 13 Gambar Hasil Uji Coba Penanganan Stok Dengan Menggunakan Perhitungan ROP (1) Gambar 14 Gambar Hasil Uji Coba Penanganan Stok Dengan Menggunakan Perhitungan ROP (2) Untuk selanjutnya adalah grafik yang berfungsi untuk menampilkan data transaksi yang telah disimpan pada database yang telah dibuat. Berikut gambar grafik pada aplikasi apotek ini. JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 8
Gambar 15 Gambar Tampilan Grafik Aplikasi. KESIMPULAN Sesudah melakukan analisis, perancangan, uji coba dan evaluasi sistem, maka dapat diambil beberapa kesimpulan, yaitu: 1. Aplikasi yang dibuat mampu mengurangi jumlah penolakan penjualan. 2. Aplikasi yang dibuat mampu memberikan informasi pembelian, penjualan, stok dan penolakan transaksi penjualan. 3. Aplikasi yang dibuat mampu menampilkan grafik dari transaksi penjualan, pembelian, stok dan penolakan penjualan. DAFTAR PUSTAKA Gaspersz, V. (2004). Production Plan & Inventory Control. Jakarta: Gramedia JSIKA Vol. 4, No. 2, September 2015, ISSN 2338-137X Page 9