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.

Harga pembelian adalah sebagian kecil dari biaya sebenarnya

Perangkat lunak memiliki biaya seumur hidup, dan biaya pembuatannya hanya sebagian saja. Aturan praktis yang masuk akal selama bertahun-tahun melakukan hal ini: pembuatan awal kira-kira 20-30% dari biaya sebenarnya yang dikeluarkan perangkat lunak selama masa pakai 3-5 tahun, 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.

Cerita lapangan: seperti apa sebenarnya "murah" itu

Sebuah perusahaan multifinance tempat saya bekerja telah membayar sistem pelacakan pinjaman yang dibangun oleh penawar terendah melalui penawaran tiga arah. Secara teknis, ini berhasil selama sekitar empat bulan. Kemudian: tidak ada validasi input, sehingga staf dapat 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: 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.

Cara membandingkan kutipan sebenarnya

Berhentilah membandingkan angka di bawah dua proposal. Bandingkan apa yang termasuk dalam masing-masing. Minta kedua vendor untuk memerinci: pengujian, penanganan kesalahan, strategi pencadangan, dokumentasi, periode dukungan pasca peluncuran. Kutipan murah biasanya muncul setelah ini dirinci, karena kutipan tersebut mengecualikan seluruhnya atau menggabungkannya ke dalam jumlah 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, 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.