Apa yang Sebenarnya Mendorong Biaya Perangkat Lunak Khusus

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.

Kenapa Layar Adalah Bagian yang Paling Murah?

Layar menjadi bagian paling murah dalam pembangunan karena secara mendasar halaman login, dashboard, atau form untuk menambahkan produk adalah pekerjaan komoditas: setiap tim yang kompeten membangunnya dengan cepat sebab polanya sudah dipahami dengan baik dan sebagian besar bisa dipakai ulang. 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:

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.
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.
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.
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.
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.

Kenapa Dua Kutipan untuk Kebutuhan yang Sama Bisa Berbeda 5x?

Dua kutipan untuk kebutuhan yang sama biasanya berbeda 5x karena yang lebih murah hanya mencakup jalur yang menyenangkan, berasumsi integrasi akan sederhana, dan tidak mengajukan cukup pertanyaan untuk mengetahui kompleksitas alur kerja sebenarnya. Hal ini tidak selalu ketidakjujuran, terkadang hanya soal 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.

Bagaimana Cara Membandingkan Kutipan dengan Tepat?

Kutipan sebaiknya dibandingkan bukan dari jumlah layar atau daftar fitur, melainkan dari apakah vendor bisa menjelaskan alur kerja, peran, pengecualian, dan integrasi bisnis Anda kembali kepada Anda dalam istilah yang spesifik, karena itulah yang benar-benar memprediksi biaya sebenarnya. 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.

Pertanyaan yang sering diajukan

Kenapa proyek pelacakan penarikan kendaraan yang terlihat sederhana bisa membengkak dari Rp180 juta menjadi hampir Rp850 juta?

Karena kebutuhan sebenarnya mencakup 15 peran pengguna di berbagai cabang, alur kerja empat tahap dengan eskalasi bersyarat, integrasi ke sistem pembiayaan inti tanpa dokumentasi API yang harus direkayasa ulang, dan kebutuhan jejak audit untuk kepatuhan regulasi, hal-hal yang tidak terlihat hanya dengan menghitung layar seperti buat kasus atau tetapkan agen.

Apakah penawaran yang murah berarti vendornya curang?

Belum tentu. Penawaran murah biasanya murah karena vendor hanya menghitung skenario ideal, mengasumsikan integrasi akan sederhana, dan tidak menggali cukup pertanyaan untuk menemukan kompleksitas alur kerja sebenarnya, yang lebih sering soal kurang pengalaman daripada niat curang. Selisihnya baru terlihat di tengah proyek, saat permintaan perubahan mulai bermunculan, waktu paling buruk untuk menyadarinya.

Kenapa 'tinggal tambah satu langkah persetujuan' bisa lebih mahal daripada seluruh modul aslinya?

Karena persetujuan satu langkah hanya satu kolom status, sementara rantai tiga langkah dengan perutean bersyarat, misalnya melewati langkah kedua bila jumlahnya di bawah ambang batas atau meningkatkan eskalasi bila langkah ketiga tertunda 48 jam, menjadi mesin status yang butuh rancangan tersendiri, bukan sekadar tambahan kolom.

Apakah migrasi data seharusnya masuk penawaran utama atau jadi item terpisah?

Migrasi data sebaiknya dibahas secara eksplisit sejak awal, bukan diasumsikan. Memindahkan spreadsheet dengan format yang tidak konsisten, database lama tanpa dokumentasi, dan kebiasaan input data manual bertahun-tahun sering kali lebih sulit daripada membangun sistem barunya, sehingga penawaran yang memperlakukan migrasi sebagai catatan kaki biasanya kurang lengkap cakupannya.