Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
ANALISIS DAN PENINGKATAN KUALITAS SISTEM INFORMASI KEUANGAN DI PT XYZ DENGAN MENGGUNAKAN METODE SEVEN TOOLS, QUALITY FUNCTION DEPLOYMENT (QFD), DAN PROTOTYPING Muchlis1) dan Daniel Oranova Siahaan2) 1) Magister Manajemen Teknologi, Institut Teknologi Sepuluh Nopember Jl. Cokroaminoto 12A, Surabaya, 60264, Indonesia e-mail:
[email protected] 2) Jurusan Teknik Informatika, Institut Teknologi Sepuluh Nopember, Surabaya ABSTRAK Sistem informasi keuangan dibutuhkan perusahaan dalam menilai kondisi riil keuangan perusahaan. Ketersediaan sistem informasi keuangan akan membantu manajemen perusahaan dalam mengontrol dan memonitor arus kas. Observasi dilakukan untuk mengidentifikasi faktor cacat pada sistem informasi keuangan yang mempengaruhi efisiensi, efektifitas serta reliabilitas laporan keuangan perusahaan. Penelitian ini menggunakan metode analisis seven tools, Quality Function Deployement (QFD), dan software prototyping. Analisis seven tools digunakan untuk mengetahui faktor cacat pada sistem informasi keuangan, metode QFD digunakan untuk menganalisis kebutuhan dan meningkatkan kualitas sistem, sedangkan software prototyping digunakan untuk memvisualisasikan kebutuhan tersebut dalam bentuk aplikasi perangkat lunak. Hasil penelitian menunjukkan bahwa terdapat tujuh faktor cacat yaitu selisih saldo kas, laporan keuangan tidak tampil, no. tanda penerimaan ganda, salah hitung denda, saldo piutang investor tidak sinkron, gagal transfer data, invoice ke pusat, dan nilai setor pajak tidak valid. Cacat tertinggi terdapat pada laporan keuangan tidak tampil. Selanjutnya hasil penyusunan rumah kualitas (house of quality) menunjukkan bahwa respon teknis dengan ranking tertinggi adalah menggunakan database yang handal sebesar 6,6% sedangkan peringkat terkecil adalah dengan mengurangi link form aplikasi dengan nilai 2,2%. Penelitian ini juga menghasilkan sebuah prototipe perangkat lunak sistem informasi keuangan yang dibuat berdasarkan deskripsi teknis (technical descriptors) pada rumah kualitas. Kata kunci: Prototipe, QFD, Sistem Informasi Keuangan, Seven Tools.
PENDAHULUAN Latar Belakang Masalah Perusahaan dituntut untuk memenuhi tata kelola yang baik dengan mempertimbangkan 5 (lima) aspek yaitu akuntabilitas, responsibilitas, transparansi, independensi, dan adil. Pencapaian tata kelola perusahaan yang baik (good corporate governance) dalam dunia usaha yang semakin kompleks menuntut adanya penyampaian produk informasi yang tepat waktu dan akurat. Untuk mencapainya perlu adanya dukungan teknologi informasi yang handal. Kualitas produk yang tinggi akan menjadi salah satu keunggulan bersaing bagi perusahaan dalam menjalankan usahanya. Suatu produk dapat dikatakan berkualitas apabila produk tersebut dapat memberi kepuasan bagi penggunanya. Kualitas produk sangat ISBN: 978-602-70604-3-2 C-7-1
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
tergantung pada seberapa baik produk yang dihasilkan memuaskan kebutuhan pengguna. Quality Function Deployment (QFD) merupakan sebuah metode yang diterapkan untuk menangkap kebutuhan pengguna dan menggunakan pengetahuan untuk mengembangkan produk yang memuaskan pengguna (Okonta dkk, 2013). Penelitian ini menggunakan obyek pada PT XYZ. Perusahaan XYZ memiliki bidang usaha utama meliputi: (a) merencanakan, membangun, serta mengembangkan kawasan industri guna penyediaan tanah, prasarana, serta fasilitas-fasilitas industri lainnya yang dibutuhkan bagi para investor, (b) melakukan kegiatan pengelolaan dan pemeliharaan atas seluruh areal kawasan industri, (c) memberi pelayanan kepada para penanam modal dalam rangka pendirian dan pengelolaan pabrik atau usaha industrinya, (d) menjual tanah matang siap bangun dan menyewakan Bangunan Pabrik Siap Pakai (BPSP) untuk keperluan usaha industri skala menengah, (e) menyewakan bangunan Sarana Usaha Industri Kecil (SUIK) untuk keperluan usaha industri skala menengah, (f) menyewakan bangunan pergudangan, (g) menyediakan kawasan berikat (EPZ) untuk perusahaan-perusahaan berorientasi ekspor. Desain aplikasi keuangan berbasis spesifikasi kebutuhan pengguna dalam penelitian ini menggunakan Quality Function Deployment (QFD), dan dalam proses desain aplikasi tersebut didukung dengan matriks perencanaan produk yaitu house of quality (HOQ) atau rumah kualitas. QFD secara sistematis menerjemahkan voice of customer menjadi persyaratan teknis dan mendokumentasi terjemahan tersebut dalam bentuk matriks HOQ. Studi Literatur Kualitas Perangkat Lunak Kualitas dari suatu perangkat lunak dinilai melalui ukuran tertentu termasuk dengan melakukan pengujian-pengujian atas perangkat lunak tersebut. Tolok ukur atau standar yang digunakan secara umum adalah yang tercantum dalam ISO 9126 yang mendefinisi kualitas produk perangkat lunak, model, karakteristik mutu, dan metrik yang terkait digunakan untuk mengevaluasi dan menetapkan kualitas produk perangkat lunak. Terdapat enam karakteristik dari kualitas yaitu (ISO 9126, 2000): 1. Fungsionalitas (Functionality) adalah kemampuan perangkat lunak untuk menyediakan fungsi sesuai kebutuhan pengguna, ketika digunakan dalam kondisi tertentu. 2. Kehandalan (Reliability) adalah kemampuan perangkat lunak untuk mempertahankan tingkat kinerja tertentu, ketika digunakan dalam kondisi tertentu. 3. Kebergunaan (Usability) adalah kemampuan perangkat lunak untuk dipahami, dipelajari, digunakan, dan menarik bagi pengguna, ketika digunakan dalam kondisi tertentu. 4. Efisiensi (Efficiency) adalah kemampuan perangkat lunak untuk memberi kinerja yang sesuai dan relatif terhadap jumlah sumber daya yang digunakan pada saat keadaan tersebut. 5. Pemeliharaan (Maintainability) adalah kemampuan perangkat lunak untuk dimodifikasi, dan modifikasi tersebut meliputi koreksi, perbaikan atau adaptasi terhadap perubahan lingkungan, persyaratan, dan spesifikasi fungsional. 6. Portabilitas (Portability) adalah kemampuan perangkat lunak untuk dapat ditransfer dari satu lingkungan ke lingkungan lain yang baru.
ISBN: 978-602-70604-3-2 C-7-2
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
Cacat Perangkat Lunak (Software Defect) Cacat perangkat lunak dapat didefinisikan sebagai cacat yang terjadi akibat dari proses pengembangan perangkat lunak. Cacat dapat timbul sejak dari tahap desain, penulisan kode program, hingga implementasi. Cacat perangkat lunak dapat muncul pada berbagai tahap proses pengembangan perangkat lunak (Pressman, 2010). Cacat merupakan faktor yang sangat berpengaruh terhadap tingkat kualitas dari perangkat lunak sehingga segera diidentifikasi faktor-faktor penyebab dari cacat tersebut. Kualitas dari perangkat lunak dapat ditingkatkan dengan cara mencegah timbulnya cacat melalui perbaikan aksi pada tahapan yang memungkinkan terjadinya cacat pada proses pengembangan perangkat lunak (Boehm dkk, 2001). Tipe Cacat Perangkat Lunak Beberapa jenis cacat didefinisi dan diklasifikasi oleh The IBM Orthogonal Defect Classification (ODC) yang dapat digunakan dan diaplikasikan secara umum oleh para pengembang perangkat lunak. ODC menyediakan suatu framework yang dapat digunakan untuk mengidentifikasi jenis-jenis cacat dan sumber dari kesalahan (error) dalam pengembangan perangkat lunak (Pachori, 2010): a. Function Cacat yang mempengaruhi kemampuan perangkat lunak secara signifikan, antarmuka pengguna akhir, antarmuka produk, dan antarmuka dengan arsitektur perangkat keras atau struktur data global. b. Logic Cacat yang mempengaruhi fungsi dari kode modul dan dapat diperbaiki dengan cara melakukan implementasi ulang pada algorithma program atau struktur data lokal dengan syarat tidak adanya permintaan kebutuhan akan perubahan desain secara global. c. Interface Cacat yang mempengaruhi interaksi dari komponen makro, call statement dan atau parameter program. d. Checking Cacat yang mempengaruhi logika program saat akan memvalidasi data dan nilai dengan benar sebelum disimpan atau digunakan dalam perhitungan. e. Assignment Cacat yang membutuhkan perubahan dalam beberapa baris kode, seperti inisialisasi blok kontrol atau struktur data. f. Timing/Serialization Cacat yang mempengaruhi ketepatan manajemen dalam membagi sumber daya secara real time. g. Build/Pakckage/Merge Cacat yang mempengaruhi versi dari produk atau konfigurasi; membutuhkan perubahan formal untuk mengkonfigurasi ulang atau membangun kembali produk. Prototipe (Prototyping) adalah pengembangan produk perangkat lunak dilakukan dalam waktu yang relatif cepat. Pengujian terhadap prototipe akan melalui proses interaksi yang berulang-ulang biasa digunakan ahli sistem informasi dan ahli bisnis. Prototyping disebut juga desain aplikasi cepat (rapid application design/RAD) karena menyederhanakan dan mempercepat desain sistem (O'Brien dkk, 2014).
ISBN: 978-602-70604-3-2 C-7-3
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
Tujuan Penelitian Penelitian ini bertujuan untuk: 1. Mengidentifikasi faktor cacat apa saja yang menyebabkan Sistem Informasi Keuangan tidak berjalan sesuai dengan kebutuhan pengguna. 2. Membuat suatu desain aplikasi sesuai dengan kebutuhan pengguna dengan menggunakan metode Quality Function Deployment dan Prototyping. 3. Meningkatkan kualitas Sistem Informasi Keuangan pada PT “XYZ” sehingga dapat menghasilkan laporan keuangan yang akurat dan tepat waktu. METODE PENELITIAN Langkah-langkah yang dilakukan dalam penelitian ini adalah: 1. Observasi secara langsung dilaksanakan pada bagian keuangan PT “XYZ” yang terletak di 4 lokasi yaitu kantor pusat, SBU-”A”, SBU-”B”, dan pada UJP dan dimulai pada bulan Oktober hingga awal bulan November 2015. Observasi ini dilakukan dengan cara melihat dan mengamati secara langsung pada masing-masing lokasi unit usaha kegiatan yang selama ini dilakukan oleh bagian keuangan dimulai dari proses pencatatan data investor, pembuatan invoice, kwitansi (TP), Surat Permintaan Pengeluaran Uang (SPPU) termasuk transaksi pencatatan piutang usaha perusahaan pada masing-masing Strategic Business Unit (SBU) hingga dibuatnya laporan keuangan perusahaan berupa Neraca, Laba-Rugi dan Arus Kas. 2. Tahap selanjutnya adalah merumuskan masalah yang timbul pada sistem informasi keuangan yang sedang berjalan saat ini termasuk penyebab dari masalah tersebut dan dampaknya terhadap sistem. 3. Setelah dilakukan observasi dan diketahui penyebab dan dampak dari tidak berjalannya sistem informasi keuangan sesuai dengan harapan dari manajemen, selanjutnya mencari dan mendalami teori-teori tentang kualitas suatu produk termasuk alat atau tools untuk mengukur kualitas diantaranya adalah seven basic tool dan teori validitas dan reliabilitas suatu data, termasuk teori tentang Quality Function Deployment dan Prototyping. 4. Populasi yang digunakan pada penelitian ini adalah seluruh karyawan PT “XYZ” dengan sampel yang digunakan dikhususkan pada pengguna yang terlibat langsung dengan sistem informasi keuangan yang tersebar pada lokasi kantor pusat, SBU-”A”, SBU-”B”, dan Unit Jasa Lain (UJL) yang keseluruhannya terdiri atas 18 pengguna. 5. Setelah menentukan populasi selanjutnya adalah melakukan wawancara secara langsung kepada user/pengguna sekaligus pengisian kuesioner oleh pengguna sistem pada bagian keuangan yang tersebar di lokasi SBU-”A”, SBU-”B”, SBU-Unit Jasa Lain (UJL), terutama pada bagian keuangan pada kantor pusat yang terbagi dalam beberapa sub bagian diantaranya bagian pencatatan Tanda Penerimaan (TP/Kwitansi), bagian pencatatan Surat Permintaan Pengeluaran Uang (SPPU), Bagian Penerimaan Faktur Pajak, bagian pencatatan piutang, bagian pencatatan buku besar, bagian pencatatan rencana dan realisasi anggaran serta bagian penyusunan laporan (laba/rugi, neraca, dan cash flow). 6. Setelah data diperoleh kemudian dilakukan uji tingkat validitas dan reliabilitas digunakan untuk mengukur kelayakan dan tingkat konsistensi dari data. Uji validitas yang digunakan pada penelitian ini adalah korelasi bivariate pearson (product momen pearson), sedangkan uji reliabilitas menggunakan metode Cronbach’s Alpha. 7. Setelah dinyatakan valid dan reliable selanjutnya data tersebut dianalisis dengan menggunakan seven tools yang terdiri atas check sheets, fishbone diagram, pareto diagram, control chart, dan flowchart . ISBN: 978-602-70604-3-2 C-7-4
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
8. Setelah dilakukan analisis dengan menggunakan seven tools, akan diketahui cacat yang akan diperbaiki, selanjutnya analisis dilakukan dengan menggunakan metode quality function deployment (QFD). Rumah kualitas (house of quality) digunakan untuk menentukan respon teknis dan ranking dari atribut kualitas yang ingin ditingkatkan sesuai dengan target/ goal dari perusahaan. HASIL DAN PEMBAHASAN Analisis Menggunakan Seven Tools Data cacat (defect) diperoleh dari hasil wawancara dan pengamatan langsung di lapangan, akan diolah dan dianalisis dengan menggunakan seven tools. Pengamatan dilakukan dengan bantuan lembar check sheets. Cacat yang telah diidentifikasi kemudian diklasifikasi dalam bentuk fishbone diagram. Setelah fishbone diagram dibuat selanjutnya dibuat Pareto diagram. Diagram ini digunakan untuk mengetahui jenis cacat (defect) yang paling sering timbul, besarnya prosentase cacat ditampilkan dalam diagram ini. Selanjutnya membuat sebuah grafik kontrol (control chart) yang berguna untuk mengetahui apakah cacat tersebut masih dalam batas kontrol ataukah tidak. Cacat yang terjadi dicatat dan direkap ke dalam Tabel 1 Tabulasi Kecacatan Sistem Informasi Keuangan. Tabel 1. Tabulasi Jenis dan Penyebab Cacat Sistem Informasi Keuangan Kode Cacat KC1 KC2 KC3 KC4 KC5 KC6 KC7
Jenis Cacat Jml Cacat Laporan Keuangan Tidak Tampil 66 Saldo Piutang Investor Tidak Sinkron 59 Selisih Saldo Kas 35 Salah Hitung Denda 35 Gagal Transfer Data Invoice ke Pusat 35 No. Tanda Penerimaan Ganda 29 Nilai Bukti Setor Pajak Tidak Valid 26 Jumlah 285
UCL 70,1 70,1 70,1 70,1 70,1 70,1 70,1
LCL 28 28 28 28 28 28 28
Gambar 1. Control Chart Cacat Sistem Informasi Keuangan Analisis Menggunakan Quality Function Deployment (QFD) Setelah tahap identifikasi cacat (defect) sistem informasi keuangan selesai dilakukan dengan menggunakan metode seven tools, langkah selanjutnya adalah dengan melakukan analisis terhadap kebutuhan pengguna Sistem Informasi Keuangan pada PT “XYZ”. Metode ISBN: 978-602-70604-3-2 C-7-5
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
Quality Function Deployment (QFD) digunakan untuk menganalisis kebutuhan dari pengguna terhadap Sistem yang diharapakan pengguna di masa mendatang. QFD memiliki beberapa tahapan yang harus dilakukan yaitu: tahap pengumpulan kebutuhan pengguna (voice of customer), tahap menyusun matrik perencanaan (planning matrix), tahap menentukan tingkat sales point yang diharapkan, tahap menentukan peningkatan dari sistem yang diharapkan (improvement ratio), tahap menentukan target/goal yang ingin dicapai, hingga tahapan menentukan tingkat prioritas (priority level) yang ingin dicapai terlebih dahulu dari sistem informasi keuangan. Dari hasil analisis terhadap tingkat kecacatan dengan menggunakan seven tools diketahui poin-poin apa saja yang perlu ditingkatkan pada sistem informasi keuangan PT XYZ”. Kebutuhan Pengguna (Customer Needs) Hasil analisis terhadap kecacatan (defect) pada sistem informasi keuangan terlihat bahwa laporan keuangan tidak tampil melebihi batas atas dari control chart sehingga membutuhkan perhatian khusus. Terdapat sembilan jenis kecacatan yang dapat diidentifikasi penyebabnya melalui proses pengisian lembar check sheets. Dari jenis kecacatan tersebut selanjutnya digunakan untuk menyusun pertanyaan yang merepresentasi kebutuhan dan tingkat kepuasan yang diharapkan pengguna dari sistem informasi keuangan. Pertanyaan tersebut mengacu pada 6 (enam) kriteria kualitas dari sistem informasi sesuai dengan ISO 9126 yaitu: fungsionalitas, kehandalan, kebergunaan, efisiensi, pemeliharaan, dan portabilitas. Pengelompokan tersebut seperti terlihat pada Tabel 2. Tabel 2. Kriteria Kualitas yang Diharapkan No 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Kriteria Kualitas Laporan keuangan tepat waktu Otorisasi akses Penelusuran data Database terintegrasi Aplikasi real time Kehandalan fungsi Transfer data periodik Memiliki support system Backup data & Recovery systems Mudah digunakan Tampilan user friendly Respon time cepat Dukungan perangkat keras Mudah direvisi bila terjadi perubahan Dapat diakses secara online Dapat dikembangkan dan diintegrasikan
Technical Response Respon teknis (technical response) adalah suatu solusi teknis yang harus dilakukan untuk meningkatkan kualitas dari sistem dalam rangka memenuhi kebutuhan pengguna. Respon teknis dapat dilihat pada Tabel 3.
ISBN: 978-602-70604-3-2 C-7-6
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
Tabel 3. Respon Teknis (Technical Response) What
How
Laporan keuangan tepat waktu Otorisasi akses
Dapat dikembangkan dan di integrasikan
Menggunakan perangkat lunak yang umum digunakan Menggunakan database yang handal
Penelusuran data
Fasilitas data historis
Transfer data periodik
Terdapat fasilitas merge data
Mudah digunakan
Tepat penggunaan komponen Memiliki fitur help Tepat penggunaan fungsi query User management access
Database terintegrasi
Mengurangi link form aplikasi Desain GUI secara umum Menggunakan teknologi Redundant Array of Independece Disks (RAID) Membangun Datacenter systems
Aplikasi real time
Aplikasi client-server
Mudah direvisi bila terjadi perubahan
General languange programming Dokumentasi sistem lengkap
Kehandalan fungsi
Standarisasi fungsi pada coding program
Dapat diakses secara online
Aplikasi berbasis WAN Aplikasi mobile
Tampilan user friendly Memiliki support system
Backup data & recovery systems Respon time cepat Dukungan perangkat keras
Cloud Backup & Recovery System Simple function in coding Menambah perangkat server dan jaringan
Prototipe Perangkat Lunak Sistem Informasi Keuangan Hasil dari penelitian ini salah satunya adalah prototipe aplikasi sistem informasi keuangan. Dengan dibuatnya prototipe diharapkan dapat memberikan gambaran nyata dari deskripsi teknis (technical descriptors) yang tercantum pada rumah kualitas. Dalam pembuatan prototipe perangkat lunak akan digambarkan Data Flow Diagram (DFD) dan Entity Relational Database (ERD) dari sistem informasi keuangan. Data Flow Diagram (DFD) Level 1 Data Flow Diagram digunakan untuk menggambarkan proses aliran data dari prototipe sistem informasi keuangan yang akan dibuat. DFD yang dibuat adalah DFD level 1 yang menggambarkan aliran data pada masing-masing proses. Berikut ini adalah DFD level 1 penerimaan kas, DFD pengeluaran kas, DFD piutang usaha dan DFD laporan keuangan. DFD Penerimaan Kas Dalam penerimaan kas terdapat 6 tahap proses aliran data yaitu tahap pembuatan faktur tagihan, tahap pembuatan Tanda Penerimaan, tahap pemutakhiran kartu piutang usaha, tahap pemutakhiran data mutasi kas harian, tahap rekonsiliasi harian dan tahap rekonsiliasi buku besar bulanan. Aliran data dimulai dari tahap (1) proses pembuatan faktur tagihan/invoice, data tagihan jatuh tempo berasal dari data kontrak tenant/investor yang ISBN: 978-602-70604-3-2 C-7-7
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
kemudian diserahkan kepada fungsi penagihan. setelah investor melakukan pembayaran maka bukti setor/transfer digunakan untuk menjalankan tahap (2) proses pembuatan Tanda Penerimaan dan menghasilkan data Tanda Penerimaan (TP). Tanda penerimaan selanjutnya digunakan oleh fungsi administrasi piutang untuk melakukan tahap (3) proses pemutakhiran data piutang yang menghasilkan data piutang tenant/investor. Tanda penerimaan juga digunakan oleh fungsi pengelola kas/bank untuk melakukan tahap (4) proses pemutakhiran buku mutasi kas harian dan tahap (5) proses rekonsiliasi harian dan menghasikan data mutasi kas. Sedangkan oleh fungsi akuntansi, Tanda Penerimaan digunakan untuk melakukan tahap (6) proses rekonsiliasi buku besar bulanan dan menghasilkan data buku besar. DFD penerimaan kas dapat dilihat pada Gambar 2.
Gambar 2. DFD Penerimaan Kas DFD Pengeluaran Kas Dalam proses pengeluaran kas terdapat 4 tahap aliran data yaitu tahap pengajuan Surat Permintaan Uang Muka (SPUM), tahap pengecekan pengeluaran uang, tahap pengeluaran uang, dan tahap pemutakhiran buku besar. aliran data dimulai dari tahap (1) proses pengajuan SPUM oleh unit kerja dan menghasilkan data SPUM yang telah diotorisasi oleh pejabat yang berwenang. Data SPUM selanjutnya diserahkan kepada fungsi keuangan untuk dilakukan tahap (2) proses pengecekan pengeluaran uang dan menghasilkan data Surat Permintaan Pengeluaran Uang (SPPU). Selanjutnya dilakukan tahap (3) yaitu proses pengeluaran uang yang dilakukan oleh fungsi pengelola kas/bank dan menghasikan data kas & bank harian. Tahap (4) fungsi akuntansi mencatat bukti SPPU dan SPUM ke dalam jurnal transaksi dan menghasilkan data buku besar. DFD pengeluaran kas dapat dilihat pada Gambar 3.
ISBN: 978-602-70604-3-2 C-7-8
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
Gambar 3. DFD Pengeluaran Kas DFD Piutang Usaha Dalam proses piutang usaha terdapat 4 tahap aliran data yaitu tahap pemeliharaan data tenang, tahap monitoring piutang usaha lewat jatuh tempo, tahap pengiriman rekening tagihan dan tahap pemutahkiran data tenant. Aliran data dimulai dari tahap (1) proses pemeliharaan data tenant oleh unit kerja dan menghasilkan data piutang dan data kontrak tenant yang telah terupdate. Data piutang digunakan oleh fungsi administrasi piutang untuk melakukan tahap (2) proses monitoring piutang usaha lewat jatuh tempo untuk digunakan oleh fungsi administrasi penagihan untuk melakukan tahap (3) proses pengiriman rekening tagihan dan menghasilkan data buku register tagihan. Tahap (4) adalah proses pemutakhiran data tenant digunakan untuk mengupdate data kartu piutang. DFD piutang usaha dapat dilihat pada Gambar 4.
Gambar 4. DFD Piutang Usaha ISBN: 978-602-70604-3-2 C-7-9
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
DFD Laporan Keuangan Dalam proses laporan keuangan terdapat 5 tahap aliran data yaitu tahap penerimaan transaksi keuangan, pengecekan validitas transaksi keuangan, posting buku besar, pembuatan laporan keuangan proforma, persetujuan laporan keuangan proforma. Aliran data dimulai dari tahap (1) proses penerimaan transaksi keuangan (TP, SPPU, dan memo internal) oleh fungsi akuntansi dari unit kerja. Tahap (2) proses pengecekan validitas transaksi keuangan, setelah data dianggap valid maka dilakukan tahap (3) proses posting ke buku besar dan menghasilkan data buku besar. Tahap (4) proses pembuatan laporan keuangan proforma, data berasal dari rekaman buku besar, selanjutnya dilakukan tahap (5) proses persetujuan laporan keuangan proforma yang menghasilkan data laporan keuangan. DFD laporan keuangan dapat dilihat pada Gambar 5.
Gambar 5. DFD Laporan Keuangan Entitiy Relational Database (ERD) Diagram ERD digunakan untuk menggambarkan relasi atau hubungan antar masing-masing Tabel dalam database. Tabel yang digunakan dalam membangun prototipe sistem informasi keuangan ini terdiri dari 25 jenis entity seperti tampak pada Tabel 4. Tabel 4. Daftar Entity Prototipe Sistem Informasi Keuangan No 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Entity SPUM mata_anggaran SPPU detail_SPPU unit_kerja BG kontrak_investor kartu_piutang invoice detil_invoice investor SPJUM dokumen_SPJUM tanda_penerimaan
Fungsi Mencatat data transaksi uang muka Mencatat data anggaran keuangan Mencatat transaksi pengeluaran uang Mencatat detail transaksi pengeluaran uang Mencatat data unit kerja perusahaan Mencatat transaksi Bilyet Giro Mencatat data kontrak sewa investor Mencatat data kartu piutang investor Mencatat tagihan/invoice ke investor Mencatat detail tagihan/invoice ke investor Mencatat data investor Mencatat permintaan uang muka Menyimpan dokumen permintaan uang muka Mencatat transaksi tanda penerimaan
ISBN: 978-602-70604-3-2 C-7-10
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
No 15 16 17 18 19 20 21 22 23 24 25
Entity detil_tanda_penerimaan bank bukti_setoran dokumen_bukti_setoran tanda_penerimaan detil_tanda_penerimaan asset jenis_transaksi buku_besar kode_akuntansi periode_akuntansi
Fungsi Mencatat detail transaksi tanda penerimaan Mencatat data bank Mencatat data bukti setoran Menyimpan dokumen bukti setor pajak Mencatat transaksi Tanda Penerimaan Mencatat detail transaksi Tanda Penerimaan Mencatat data aset Mencatat data jenis transaksi Mencatat transaksi buku besar Mencatat kode rekening akuntansi Mencatat periode akuntansi
Gambar 6. Entity Relational Database Prototipe Sistem Informasi Keuangan KESIMPULAN DAN SARAN Kesimpulan Berdasarkan hasil analisis data dapat disimpulkan bahwa terdapat tujuh jenis cacat pada sistem informasi keuangan. Ketujuh jenis cacat tersebut yaitu selisih saldo kas sebanyak 35 kali atau sebesar 12%, laporan keuangan tidak tampil sebanyak 66 kali atau sebesar 23%, no tanda penerimaan ganda sebanyak 29 kali atau sebesar 10%, salah hitung denda sebanyak 35 kali atau sebesar 12%, saldo piutang investor tidak sinkron sebanyak 59 kali atau sebesar 21%, gagal transfer data invoice ke pusat sebanyak 35 kali atau sebesar 12% dan nilai setor pajak tidak valid sebanyak 26 kali atau sebesar 9%. Dari ketujuh jenis cacat tersebut jumlah terbanyak terjadi pada laporan keuangan tidak tampil yang disebabkan oleh aplikasi error, server down, koneksi sering putus dan dBASE digunakan masih parsial. Hasil perhitungan menggunakan analisis control chart menunjukkan terdapat 2 jenis cacat melebihi batas kontrol atas (UCL) yaitu laporan keuangan tidak tampil dan saldo piutang investor tidak sinkron. Hasil dari penyebaran kuesioner tingkat kepentingan pengguna (importance to customer) dan tingkat kepuasan dari pengguna (customer satisfaction performance) sistem informasi keuangan diperoleh 16 atribut kualitas yang perlu untuk ditingkatkan oleh ISBN: 978-602-70604-3-2 C-7-11
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
perusahaan yaitu mudah digunakan, laporan keuangan tepat waktu, otorisasi akses, dapat dikembangkan dan diintegrasikan, penelusuran data, transfer data periodik, tampilan user friendly, memiliki support system, database terintegrasi, aplikasi real time, mudah direvisi bila terjadi perubahan, kehandalan fungsi, dapat diakses secara online, backup data & recovery systems, respon time cepat, dan dukungan perangkat keras. Berdasarkan analisis Quality Function Deployment dengan menggunakan house of quality dari 16 atribut kualitas diperoleh 21 respon teknis yang perlu dilaksanakan. Respon teknis terhadap atribut mudah digunakan adalah dengan cara menggunakan komponen aplikasi yang tepat pada tampilan tatap muka/GUI, dan menambahkan fasilitas bantuan (help) agar mudah untuk digunakan. respon teknis terhadap atribut laporan keuangan tepat waktu adalah dengan cara menggunakan fungsi query program dengan tepat, dan respon teknis untuk otorisasi akses adalah dengan memberi fasilitas user management access. Respon teknis terhadap sistem dapat dikembangkan dan di integrasikan adalah dengan menggunakan perangkat lunak yang umum digunakan, dan menggunakan database yang handal. Respon teknis terhadap penelusuran data adalah dengan cara memberikan fasilitas pencarian data historis. Respon teknis terhadap transfer data periodik adalah memberi fasilitas merge data, sedangkan respon teknis terhadap tampilan user friendly adalah dengan mengurangi link form pada aplikasi dan menggunakan desain tampilan grafis/GUI secara umum. Respon teknis terhadap memiliki support system adalah dengan menggunakan teknologi RAID, sedangkan respon teknis terhadap database terintegrasi adalah dengan membangun datacenter systems. Respon teknis terhadap mudah direvisi bila terjadi perubahan adalah dengan menggunakan bahasa pemrograman yang umum digunakan (general languange programming) membuat dokumentasi sistem secara lengkap. Respon teknis terhadap kehandalan fungsi adalah dengan melakukan standarisasi fungsi dan coding program, dan respon teknis terhadap dapat diakses secara online adalah dengan membangun aplikasi berbasis Wide Area Network (WAN) dan aplikasi mobile. Respon teknis terhadap backup data & recovery systems adalah dengan membuat backup data berbasis cloud dan membuat recovery system. Respon teknis terhadap respon time cepat adalah dengan menggunakan coding program yang mudah (simple function in coding). Respon teknis terhadap dukungan perangkat keras adalah dengan menambah perangkat server dan jaringan. Berdasarkan nilai dari weight/importance bagi pengguna sistem informasi keuangan ranking pertama adalah menggunakan database yang handal yaitu sebesar 165,32 atau sebesar 6,6% untuk nilai relative weight and percent. Saran 1. Faktor cacat yang dibahas dalam penelitian ini terbatas pada transaksi penerimaan dan pengeluaran kas yang berkaitan dengan piutang perusahaan, sedangkan faktor cacat dapat juga terjadi pada transaksi yang berhubungan dengan sistem gaji dan upah, penyusunan anggaran perusahaan dan pada penyusunan laporan keuangan konsolidasi pusat dan cabang (laporan keuangan konsolidasi). Sehingga faktor cacat tersebut dapat dimasukkan dalam atribut kualitas yang perlu ditingkatkan pada penelitian selanjutnya. 2. Technical descriptors pada penelitian ini terbatas pada 21 jenis respon teknis (technical response), masih terdapat respon teknis lainnya yang berpengaruh terhadap kualitas dari sistem informasi keuangan seperti membangun Online Analytical Processing/Business Intelligence, datawarehouse, online transaction processing (OLTP) dan dapat dimasukkan dalam technical descriptors pada penelitian selanjutnya. 3. Prototipe dari sistem informasi keuangan pada penelitian ini menggunakan high fidelity prototipe yang menggambarkan secara rinci dari sistem namun terbatas pada fitur pembuatan invoice, buku pembantu piutang, dan penyusunan laporan keuangan individu. Buku pembantu utang, anggaran perusahaan dan laporan keuangan konsolidasi tidak ISBN: 978-602-70604-3-2 C-7-12
Prosiding Seminar Nasional Manajemen Teknologi XXIV Program Studi MMT-ITS, Surabaya 23 Januari 2016
termasuk dalam prototipe ini. Sehingga fitur tersebut dapat dimasukkan dalam pembuatan prototipe pada penelitian selanjutnya. DAFTAR PUSTAKA Boehm, Barry. dan Basili Victor R. (2001). Software Defect Reduction Top 10 List. IEEE Transaction on Computer , 34 (1). ISO 9126. (2000). Information technology - Software product quality - part 1: Quality model. International Standard Organization. International Standard Organization (ISO). O'Brien, J. A., James, A. dan Marakas, George M. (2014). Sistem Informasi Manajemen (9 ed.). Salemba Empat. Okonta, O. E., Ojugo, A.A, Wemembu, U.R, Dele, A. (2013). Embedding Quality Function Deployment In Software Development: A Novel Approach. Pachori, P. T. (2010). Modelling and Analysing of Software Defect Prevention Using ODC. International Journal of Advanced Computer Science and Applications (IJACSA) , 1 (3). Pressman, R. S. (2010). Software Engineering A Practitioner's Approach (7th Edition ed.). New York, USA: McGrawHill.
ISBN: 978-602-70604-3-2 C-7-13