Setiap pendiri yang meminta tiga vendor untuk memberikan penawaran pada "aplikasi yang sama" akan mendapatkan tiga nomor yang sangat berbeda, dan kemudian berasumsi bahwa seseorang berbohong. Tidak ada yang berbohong. Biaya pengembangan perangkat lunak khusus hampir tidak pernah sesuai dengan apa yang menurut klien mereka bayar, yaitu layar dan fitur. Ini sejalan dengan apa yang sebenarnya harus dibangun oleh vendor, yaitu logika keputusan, dan kedua hal tersebut hanya terkait secara longgar.

Saya telah duduk di kedua sisi ini. Sebagai vendor, saya telah mengutip sebuah proyek dengan harga 5x lipat dari yang dikutip pesaing, karena apa yang tampak di atas kertas seperti laporan singkat yang sama. Sebagai pemimpin teknis yang berhadapan dengan klien, saya harus menjelaskan kepada pemilik bisnis mengapa "tambahkan saja langkah persetujuan" lebih mahal daripada keseluruhan modul asli. Kesenjangan ini nyata dan dapat dijelaskan jika Anda tahu di mana mencarinya.

Layar Adalah Bagian Yang Paling Murah

Halaman login, dashboard, form untuk menambahkan produk. Ini adalah pekerjaan komoditas. Setiap tim yang kompeten akan membangunnya dengan cepat karena polanya dipahami dengan baik dan sebagian besar dapat digunakan kembali. Jika RFP Anda mendeskripsikan produk sebagai daftar layar, Anda akan mendapatkan penawaran yang sangat bervariasi, karena jumlah layar hampir tidak memberi tahu vendor apa pun tentang upaya rekayasa sebenarnya di baliknya.

Yang sebenarnya memerlukan biaya adalah apa yang terjadi ketika layar harus mengambil keputusan. Layar "buat faktur" murah. Sebuah "membuat faktur yang mengubah perlakuan pajak berdasarkan jenis pelanggan, menerapkan aturan pembulatan yang berbeda untuk uang tunai versus transfer, dan memblokir pengiriman jika pelanggan memiliki saldo yang telah jatuh tempo" adalah layar yang sama, lima kali lipat biayanya.

Penggerak Biaya Nyata

Urutan seberapa sering mereka membuat perkiraan:

  1. Jumlah peran pengguna dan kombinasi izin. Dua peran (admin, staf) sederhana. Enam peran dengan izin yang tumpang tindih dan visibilitas berbasis peran di setiap layar melipatgandakan pengujian dan penanganan kasus tepi, bukan hanya tabel izin.
  2. Rantai persetujuan dan status alur kerja. Persetujuan satu langkah adalah satu bidang status. Rantai tiga langkah dengan perutean bersyarat (lewati langkah kedua jika jumlahnya di bawah ambang batas, tingkatkan jika langkah ketiga tertunda 48 jam) adalah mesin negara yang memerlukan izin desainnya sendiri.
  3. Integrasi ke sistem lama. Ini biasanya merupakan underquote vendor item baris terbesar, karena tidak ada yang mengetahui perilaku sebenarnya dari sistem lama sampai mereka berada di dalamnya. Integrasi sistem akuntansi yang "hanya sebuah API" dapat memakan waktu berminggu-minggu untuk menangani keanehan lapangan yang tidak terdokumentasi, batas laju, dan kegagalan diam-diam.
  4. Penanganan pengecualian. Apa yang terjadi ketika internet terputus di tengah transaksi. Apa yang terjadi jika dua staf mengedit catatan yang sama sekaligus. Apa yang terjadi jika data pelanggan tidak sesuai dengan model yang Anda rancang. Sistem yang hanya menangani jalur bahagia adalah sistem yang murah untuk dibangun dan mahal untuk dijalankan.
  5. Migrasi data dari apa pun yang ada saat ini. Spreadsheet dengan format yang tidak konsisten, database lama tanpa dokumentasi, penyelesaian manual selama bertahun-tahun dimasukkan ke dalam "cara staf sebenarnya memasukkan data". Memigrasikan kekacauan tersebut seringkali lebih sulit daripada membangun sistem baru.

Tak satu pun dari ini muncul saat Anda menghitung layar. Semuanya muncul di faktur.

Mengapa Dua Kutipan untuk Ringkasan yang Sama Berbeda 5xPenawaran yang lebih murah biasanya lebih murah karena vendor hanya mencakup jalur yang menyenangkan, berasumsi bahwa integrasi akan sederhana, dan tidak mengajukan cukup banyak pertanyaan untuk mengetahui kompleksitas alur kerja sebenarnya. Hal ini tidak selalu merupakan ketidakjujuran. Terkadang itu karena kurangnya pengalaman. Apa pun yang terjadi, Anda akan mengetahui kebenarannya di tengah proyek, saat permintaan perubahan dimulai, yang merupakan waktu terburuk untuk mengetahuinya.

Penawaran yang lebih mahal terkadang bersifat tambahan, namun sering kali penawaran tersebut mencerminkan vendor yang benar-benar menanyakan tentang rantai persetujuan Anda, kasus pengecualian, dan sistem lama Anda sebelum menentukan harga. Percakapan itu layak dilakukan sebelum Anda menandatangani, bukan setelahnya.

Jika bisnis Anda sudah melampaui spreadsheet ad hoc dan solusi manual, peralihan ke perangkat lunak khusus biasanya bukan tentang antarmuka, melainkan tentang pengkodean alur kerja dengan benar. Bacaan terkait: Tujuh Tanda Bisnis Anda Telah Melebihi Spreadsheet.

Pertanyaan yang Mengungkap Perbedaan Nyata

Sebelum membandingkan penawaran harga saja, tanyakan pada masing-masing vendor:

  • Berapa banyak peran pengguna yang Anda ambil, dan izin apa yang berbeda di antara peran tersebut?
  • Sistem saya saat ini yang mana yang memerlukan hal ini, dan pernahkah Anda melihat dokumentasi API-nya?
  • Apa yang terjadi pada desain Anda ketika [kasus tepi tertentu dalam bisnis Anda] terjadi?
  • Apakah migrasi data dari sistem saya saat ini disertakan, atau merupakan item baris terpisah?
  • Apa asumsi Anda tentang alur kerja persetujuan, dalam bahasa sederhana, bukan fitur?

Vendor yang menjawab pertanyaan ini secara spesifik sebenarnya telah mencakup bisnis Anda. Vendor yang menjawab secara umum telah mencakup aplikasi umum yang mirip dengan milik Anda.

Contoh Konkret

Sebuah perusahaan multifinance tempat saya bekerja meminta alat internal yang "sederhana" untuk melacak kasus penarikan kembali kendaraan. Kutipan pertama memperlakukannya sebagai aplikasi CRUD: membuat kasus, menetapkan agen lapangan, menandai ditutup. Rp180 juta, empat minggu.

Persyaratan sebenarnya, setelah kami menggali: 15 peran pengguna yang berbeda di seluruh cabang, alur kerja empat tahap dengan eskalasi bersyarat tergantung pada respons debitur, integrasi ke sistem pembiayaan inti yang tidak memiliki dokumentasi API dan memerlukan rekayasa ulang database lama, dan persyaratan jejak audit untuk setiap perubahan status karena kepatuhan terhadap peraturan. Biaya sebenarnya: mendekati Rp850 juta, dan bernilai setiap rupiah karena alur kerja yang salah berarti memproses ulang kasus secara manual.

Layarnya tampak hampir sama di kedua cakupan. Logika keputusan di bawahnya tidak demikian.

Kesimpulan Praktis

Berhenti membandingkan kutipan berdasarkan jumlah layar atau daftar fitur. Bandingkan berdasarkan apakah vendor dapat menjelaskan alur kerja, peran, pengecualian, dan integrasi aktual Anda kepada Anda dalam istilah yang spesifik. Kutipan yang tidak menyebutkan hal-hal tersebut adalah tebakan yang dibalut sebagai angka, dan biaya sebenarnya akan muncul kemudian sebagai permintaan perubahan yang tidak Anda anggarkan. Jika Anda menginginkan pendapat kedua tentang suatu penawaran sebelum Anda menandatanganinya, itu adalah percakapan lima menit yang layak untuk dilakukan: hubungi melalui /partner.