# Mengapa Perangkat Lunak Murah Adalah Jenis Yang Paling Mahal > Biaya tersembunyi perangkat lunak murah muncul setelah pembelian: pengerjaan ulang, kehilangan data, peluncuran yang ditinggalkan, dan pembangunan kembali. Mengapa tawaran terendah biasanya menghabiskan biaya paling besar secara keseluruhan. Canonical: https://www.ervandra.com/id/blog/why-cheap-software-is-expensive Author: Ervandra Halim Date: 2025-05-08 Penawaran terendah dalam perbandingan vendor jarang sekali merupakan pilihan termurah setelah proyek benar-benar selesai, diterapkan, dan dijalankan dalam bisnis Anda selama dua tahun. Biaya tersembunyi perangkat lunak murah tidak muncul di faktur, biaya tersebut muncul enam bulan kemudian sebagai pengerjaan ulang, kehilangan data, peluncuran yang tidak dipercaya oleh siapa pun, atau pembangunan kembali yang memerlukan biaya lebih besar daripada proyek awal jika dilakukan dengan benar pada kali pertama. Saya telah membangun kembali sistem yang sama dua kali untuk dua klien berbeda, keduanya membayar vendor diskon terlebih dahulu karena nomornya terlihat bagus di samping penawaran dari tim yang lebih berpengalaman. Dalam kedua kasus tersebut, harga pembeliannya mungkin 60% dari harga bangunan kokoh. Dalam kedua kasus tersebut, total biaya, setelah Anda menambahkan pembangunan kembali, berakhir pada 250-300% dari penawaran "mahal" yang mereka tolak. Ini bukan ceramah tentang membayar lebih demi hal itu. Ini tentang memahami apa yang sebenarnya diwakili oleh harga stiker, dan apa yang tidak diwakili oleh harga stiker. ## Seberapa besar porsi harga beli dari total biaya sebenarnya? Harga pembelian hanya menutup sekitar 20-30% dari biaya sebenarnya yang dikeluarkan perangkat lunak selama masa pakai 3-5 tahun, berdasarkan aturan praktis dari pengalaman bertahun-tahun menangani proyek semacam ini. Perangkat lunak memiliki biaya seumur hidup, dan biaya pembuatannya hanya potongan pertama saja. Sisa 70-80% baru muncul setelah Anda menghitung: - Hosting dan infrastruktur selama bertahun-tahun - Perbaikan bug untuk masalah yang seharusnya tidak pernah dikirimkan - Tiket dukungan dari antarmuka yang membingungkan atau rusak - Waktu staf terbuang untuk menyelesaikan masalah karena fitur dibuat setengah jadi - Pembersihan data ketika desain database tidak tahan - Pembangunan kembali pada akhirnya, ketika "murah" menjadi "tidak dapat digunakan" Vendor diskon bersaing pada potongan pertama itu. Mereka tidak dapat bersaing dengan 70-80% lainnya, karena mengambil jalan pintas dalam hal arsitektur, pengujian, dan desain datalah yang membuat mereka mencapai angka serendah itu. Sudut-sudutnya tidak hilang, mereka bergerak ke hilir, dan ke hilir adalah tempat Anda terjebak hidup bersama mereka setiap hari. > Sudut-sudutnya tidak hilang, mereka bergerak ke hilir, dan ke hilir adalah tempat Anda terjebak hidup bersama mereka setiap hari. > > Ervandra Halim ## Seperti apa sebenarnya wajah "murah" itu di lapangan? Wajah "murah" di lapangan terlihat pada sistem pelacakan pinjaman yang dibangun oleh penawar terendah untuk sebuah perusahaan multifinance, hasil dari penawaran tiga arah yang secara teknis berhasil selama sekitar empat bulan sebelum celahnya terlihat: tidak ada validasi input, sehingga staf bisa menyimpan catatan pinjaman dengan tanggal yang tidak mungkin. Tidak ada pengindeksan yang tepat, sehingga basis data melambat menjadi perayapan setelah jumlah catatan melewati beberapa ribu. Tidak ada pencadangan otomatis yang dikonfigurasi, hanya ditemukan setelah server dihidupkan ulang dan menghapus transaksi selama tiga minggu. Harga build asli kurang dari setengah harga runner-up. Pembangunan kembali, jika dilakukan dengan benar, memerlukan biaya yang lebih besar dibandingkan harga kedua ditambah gabungan harga asli, karena kami juga harus memulihkan dan merekonsiliasi data yang rusak. Sebuah jaringan retail di Tangerang memiliki cerita serupa mengenai integrasi point-of-sale. Build murah "berhasil" di demo. Dalam produksi, berdasarkan volume transaksi nyata selama penjualan akhir pekan, kasir mengunci kasir selama sebelas menit per toko, dua kali sehari, setiap hari, selama tiga bulan sebelum ada orang yang meningkatkannya dengan cukup keras untuk mendapatkan perhatian. Sebelas menit pencatatan yang ditutup pada jam sibuk, berapa pun banyaknya transaksi yang mewakili, dikalikan tiga bulan, merupakan kerugian pendapatan yang nyata dan dapat dihitung yang tidak pernah muncul dalam spreadsheet anggaran siapa pun, karena tidak pernah dihargai sebagai biaya pembangunan yang murah. ## Tiga pertanyaan yang mengungkap jalan pintas sebelum Anda menandatangani Anda tidak perlu menjadi teknis untuk menanyakan hal ini. Anda memerlukan vendor untuk menjawabnya tanpa menyimpang.1. **"Beri tahu saya apa yang terjadi jika 10x lebih banyak pengguna melakukan ini sekaligus dibandingkan saat demo."** Vendor yang serius memiliki jawaban aktual yang melibatkan pengujian beban atau pilihan arsitektur. Pemotong sudut mengubah subjek menjadi fitur. 2. **"Apa rencana Anda khususnya untuk pencadangan dan pemulihan bencana?"** Jawaban yang tidak jelas ("server menanganinya") berarti tidak ditangani. Anda menginginkan jadwal tertentu dan waktu pemulihan tertentu. 3. **"Dapatkah saya melihat cara Anda menangani kasus ketika data masukan salah atau tidak lengkap?"** Ini memberi tahu Anda apakah penanganan kesalahan benar-benar dibuat, atau apakah sistem hanya mengasumsikan semua orang memasukkan data sempurna selamanya. Ini adalah mode kegagalan yang sama yang tercakup dalam [Data Pelanggan: Kumpulkan Lebih Sedikit, Gunakan Lebih Banyak](/blog/customer-data-collect-what-matters): sistem yang tidak memvalidasi apa yang masuk pada akhirnya tenggelam dalam apa yang tidak dapat mereka gunakan. Jika vendor tidak dapat menjawab pertanyaan ini secara spesifik, angka rendahnya adalah rendah karena hal ini tidak dibuat, bukan karena mereka menemukan efisiensi yang tidak terpikirkan oleh Anda. ## Bagaimana cara membandingkan penawaran vendor yang sebenarnya? Membandingkan penawaran vendor yang sebenarnya berarti membandingkan apa yang termasuk di masing-masing proposal, bukan angka di baris paling bawah. Minta kedua vendor merinci pengujian, penanganan kesalahan, strategi pencadangan, dokumentasi, dan periode dukungan pasca-peluncuran; penawaran murah biasanya langsung terlihat begitu ini dirinci, karena salah satu vendor mengecualikannya sepenuhnya atau membungkusnya dalam angka kecil yang mencurigakan. Latihan perincian ini sendiri telah menyelamatkan klien dari keputusan buruk bahkan sebelum kontrak ditandatangani, dan ini berpasangan dengan baik dengan memetakan proses Anda yang sebenarnya terlebih dahulu, seperti yang dibahas dalam [Petakan Proses Sebelum Anda Mengotomatiskannya](/blog/process-mapping-before-automation), sehingga Anda membandingkan penawaran dengan cakupan sebenarnya, bukan cakupan samar yang diinterpretasikan secara berbeda oleh kedua vendor. ## Kesimpulannya Nilailah vendor perangkat lunak berdasarkan total biaya kepemilikan, bukan angka di bagian bawah penawaran. Tanyakan tentang skala, pencadangan, dan penanganan kesalahan sebelum Anda menandatangani, bukan setelah terjadi kerusakan. Sebuah bangunan yang biayanya 40% lebih mahal di muka namun tetap bertahan akan lebih murah, setiap saat, dibandingkan bangunan diskon yang akan terpaksa Anda bangun kembali dalam waktu satu tahun. Jika Anda sedang mengevaluasi penawaran saat ini dan menginginkan pendapat kedua tentang apa yang sebenarnya dihargai atau ditinggalkan, ada baiknya untuk berdiskusi sebelum Anda berkomitmen, bukan setelahnya.