Cara Membaca Proposal dari Software House

Dua proposal, dua angka yang beda jauh — satu Rp45 juta, satu Rp95 juta. Sekilas keduanya menjanjikan “sistem manajemen inventori lengkap”. Setelah dibaca lebih teliti, yang murah ternyata tidak menyebutkan migrasi data sama sekali, sementara yang mahal sudah mencakup migrasi, pelatihan tiga sesi, dan enam bulan dukungan penuh.

Setelah menghubungi beberapa software house, Anda akan menerima proposal dengan format, struktur, dan harga yang beragam. Membandingkan angka totalnya saja hampir selalu menyesatkan, karena setiap proposal mungkin mencakup pekerjaan yang sangat berbeda meski judulnya terdengar sama. Artikel ini membantu Anda membaca proposal dengan lebih kritis, bagian per bagian.

Ringkasan

• Bagian terpenting proposal adalah ruang lingkup, bukan angka harga
• Periksa hal yang sering tidak tertulis: migrasi data, integrasi, pelatihan, biaya pihak ketiga
• Pahami cara perubahan kebutuhan dihitung sebelum menandatangani
• Harga yang jauh lebih murah dari yang lain perlu dipertanyakan alasannya
• Perhatikan tahapan, pembayaran, dan pertanyaan yang diajukan vendor

Kenapa membandingkan angka saja menyesatkan

Setiap software house memiliki cara berbeda menyusun proposal. Sebagian mencantumkan semua biaya secara rinci dan transparan sejak awal. Sebagian lain memberi angka yang terlihat menarik, tapi sebenarnya baru mencakup sebagian kecil dari yang sebenarnya Anda butuhkan — sisanya akan ditagih terpisah begitu pengerjaan berjalan dan kebutuhan tambahan “ditemukan”.

Tanpa membaca detail ruang lingkup, Anda tidak benar-benar membandingkan harga untuk pekerjaan yang sama. Anda membandingkan dua hal yang berbeda hanya karena kebetulan angka totalnya muncul di kolom yang sama.

Periksa ruang lingkup lebih dulu

Bagian terpenting proposal bukan harga, melainkan daftar pekerjaan yang dicakup di dalamnya. Cocokkan dengan dokumen kebutuhan Anda satu per satu: apakah semua kebutuhan wajib benar-benar tercakup secara eksplisit? Apa saja yang tidak disebutkan sama sekali? Sebagai aturan praktis, kebutuhan yang tidak tertulis di proposal sebaiknya dianggap tidak termasuk, meski secara lisan vendor mengatakan “itu pasti kami kerjakan juga kok”.

Hal yang sering tidak tertulis

• Migrasi data dari sistem atau spreadsheet lama ke sistem baru
• Integrasi dengan aplikasi lain yang sudah dipakai perusahaan
• Pelatihan pengguna dan penyusunan dokumentasi
• Biaya server, domain, dan layanan pihak ketiga lainnya
• Masa perbaikan bug setelah sistem diluncurkan
• Biaya pemeliharaan bulanan setelah masa perbaikan berakhir

Jika salah satu dari hal-hal ini tidak disebutkan, jangan berasumsi itu sudah termasuk. Tanyakan secara eksplisit dan minta jawaban tertulis, bukan hanya konfirmasi lisan yang mudah dilupakan atau disangkal di kemudian hari.

Pahami cara perubahan dihitung

Kebutuhan hampir pasti berubah selama pengerjaan berlangsung — itu wajar dalam project software apa pun. Proposal yang baik menjelaskan bagaimana perubahan ditangani: apakah ada ruang untuk penyesuaian kecil tanpa biaya tambahan, dan bagaimana tambahan fitur yang lebih besar dihitung dan disepakati. Tanpa penjelasan ini, perubahan kecil yang terasa wajar bagi Anda bisa berujung pada tagihan tambahan yang tidak terduga.

Lihat tahapan dan skema pembayaran

Periksa bagaimana pekerjaan dibagi dalam tahapan, apa hasil konkret yang diserahkan di setiap tahap, dan bagaimana termin pembayaran dikaitkan dengan hasil tersebut. Skema yang mengaitkan pembayaran dengan hasil yang bisa dicoba dan diverifikasi — bukan sekadar persentase waktu yang berlalu — memberi Anda kendali yang lebih baik jika project ternyata tidak berjalan sesuai harapan.

Perhatikan pertanyaan yang diajukan vendor

Vendor yang mengajukan banyak pertanyaan tentang proses bisnis Anda sebelum mengirim proposal biasanya memahami risiko project dengan lebih baik, dan proposalnya cenderung lebih akurat mencerminkan kebutuhan sebenarnya. Proposal yang datang sangat cepat tanpa pertanyaan apa pun — hanya berdasarkan pesan singkat awal Anda — layak dibaca dengan lebih hati-hati, karena kemungkinan besar berdasarkan asumsi yang belum diverifikasi.

Membaca bagian teknis tanpa perlu jadi ahli teknis

Anda tidak perlu memahami istilah teknis mendalam untuk menilai proposal. Yang perlu diperhatikan adalah apakah penjelasan teknisnya masuk akal secara logika bisnis: apakah teknologi yang disebutkan sesuai dengan skala kebutuhan Anda, dan apakah vendor bisa menjelaskan pilihan teknisnya dalam bahasa yang Anda pahami ketika ditanya. Vendor yang baik bisa menerjemahkan keputusan teknis menjadi dampak bisnis yang jelas.

Ilustrasi: membaca dua proposal berdampingan

Bayangkan Anda menerima dua proposal untuk sistem manajemen gudang. Proposal A senilai Rp60 juta dengan deskripsi singkat: “Sistem manajemen gudang lengkap dengan laporan.” Proposal B senilai Rp85 juta dengan rincian: pemetaan proses, modul penerimaan dan pengeluaran barang, migrasi data 5.000 SKU, integrasi dengan sistem akuntansi yang sudah dipakai, pelatihan tiga sesi untuk staf gudang, dan enam bulan dukungan pasca-rilis.

Setelah Anda menanyakan detail ke vendor A, ternyata migrasi data dan integrasi akuntansi tidak termasuk dan akan ditagih terpisah — yang jika dijumlahkan, totalnya justru melebihi proposal B. Tanpa membaca detail ruang lingkup lebih dulu, Anda hampir memilih proposal yang terlihat lebih murah padahal sebenarnya lebih mahal untuk cakupan pekerjaan yang setara.

Minta klarifikasi tertulis untuk setiap keraguan

Jika ada bagian proposal yang tidak jelas, minta penjelasan tertulis melalui email atau dokumen resmi, dan pastikan jawabannya dilampirkan atau dirujuk sebagai bagian dari kontrak yang akan ditandatangani. Kesepakatan lisan yang hanya dibicarakan saat pertemuan mudah terlupakan atau ditafsirkan berbeda ketika project sudah berjalan dan masalah muncul.

Checklist membaca proposal

1. 01Cocokkan ruang lingkup dengan dokumen kebutuhan Anda satu per satu
2. 02Periksa apakah migrasi, integrasi, dan pelatihan disebutkan eksplisit
3. 03Pahami mekanisme perubahan kebutuhan dan biayanya
4. 04Perhatikan tahapan dan bagaimana pembayaran dikaitkan dengan hasil
5. 05Tanyakan apa yang membuat harga berbeda jika dibandingkan penawaran lain
6. 06Minta semua klarifikasi secara tertulis

Pertanyaan yang sering muncul

Bolehkah meminta proposal direvisi sebelum menandatangani?

Sangat boleh, dan ini bagian normal dari proses negosiasi. Vendor yang profesional akan bersedia merevisi proposal berdasarkan klarifikasi yang Anda minta, selama perubahan tersebut wajar dan tidak mengubah kesepakatan dasar secara drastis.

Apakah proposal yang lebih detail selalu lebih baik?

Umumnya ya, karena detail menunjukkan pemahaman yang lebih mendalam. Tapi periksa juga apakah detailnya relevan dan bukan sekadar dokumen panjang berisi istilah teknis yang tidak menjelaskan apa pun secara konkret tentang apa yang akan Anda terima.

Periksa klausul kepemilikan kode dan data

Salah satu bagian yang paling sering terlewat saat membaca proposal adalah siapa yang memiliki kode sumber dan data setelah project selesai. Sebagian software house secara default menyerahkan kepemilikan penuh kepada klien setelah pelunasan, tapi sebagian lain hanya memberikan lisensi pemakaian sementara kode tetap menjadi milik vendor. Perbedaan ini sangat menentukan: jika suatu saat Anda ingin pindah vendor untuk pemeliharaan atau pengembangan lanjutan, kepemilikan kode yang jelas membuat perpindahan itu mungkin dilakukan. Tanpa kejelasan ini, Anda bisa terjebak bergantung pada satu vendor selamanya, meski hubungan kerja sama sudah tidak lagi terasa nyaman.

Pahami siapa yang akan mengerjakan project Anda

Proposal sering ditulis dan dipresentasikan oleh orang yang paling senior di perusahaan software house tersebut, tapi pengerjaan sehari-hari belum tentu dilakukan oleh orang yang sama. Tanyakan secara spesifik siapa yang akan menjadi penanggung jawab teknis project Anda, berapa lama pengalaman mereka, dan apakah mereka akan tetap berada di tim yang sama sepanjang project berjalan. Pergantian anggota tim di tengah jalan — terutama jika terjadi berkali-kali — bisa memperlambat project secara signifikan karena pengetahuan tentang kebutuhan Anda harus dibangun ulang dari awal oleh orang yang baru bergabung.

Perhatikan realistis tidaknya estimasi waktu pengerjaan

Waspadai proposal yang menjanjikan waktu pengerjaan sangat singkat untuk ruang lingkup yang sebenarnya kompleks. Estimasi waktu yang terlalu optimis sering berujung pada keterlambatan yang pada akhirnya merugikan Anda juga, karena rencana bisnis yang bergantung pada tanggal peluncuran ikut mundur mengikutinya. Bandingkan estimasi waktu antar proposal untuk ruang lingkup yang setara, dan tanyakan dasar perhitungan dari estimasi tersebut — apakah berdasarkan pengalaman mengerjakan project serupa sebelumnya, atau sekadar perkiraan kasar supaya proposal terlihat lebih menarik di atas kertas.

Baca ketentuan garansi dan terminasi kontrak

Proposal yang baik menjelaskan dengan jelas apa yang terjadi jika ada pihak yang ingin menghentikan kerja sama sebelum project selesai — baik karena vendor tidak mampu memenuhi tenggat, atau karena kebutuhan bisnis Anda berubah drastis di tengah jalan. Periksa juga masa garansi setelah sistem diluncurkan: berapa lama masa berlakunya, apa saja yang tercakup di dalamnya, dan apakah perbaikan bug termasuk gratis atau justru dikenakan biaya tambahan. Ketentuan yang tidak jelas di bagian ini sering menjadi sumber perselisihan paling besar ketika hubungan kerja sama ternyata tidak berjalan semulus yang dibayangkan.

Apakah wajar meminta referensi dari klien sebelumnya?

Sangat wajar, dan sebaiknya selalu dilakukan untuk project bernilai besar. Vendor yang memiliki rekam jejak baik biasanya tidak keberatan menghubungkan Anda dengan klien sebelumnya yang bisa memberi gambaran nyata tentang cara kerja mereka sehari-hari. Kalau vendor enggan memberikan referensi sama sekali tanpa alasan yang masuk akal, jadikan itu sebagai salah satu pertimbangan tambahan sebelum memutuskan.

Perhatikan bahasa yang terlalu umum atau ambigu

Frasa seperti “sistem yang user-friendly” atau “dashboard yang lengkap” terdengar meyakinkan tapi sebenarnya tidak menjelaskan apa pun secara konkret tentang apa yang akan Anda terima. Proposal yang baik menerjemahkan klaim semacam ini menjadi hal yang bisa diverifikasi: fitur apa saja yang termasuk dalam dashboard tersebut, laporan apa yang bisa dihasilkan, dan bagaimana bentuknya secara spesifik.

Jika Anda menemukan proposal yang penuh dengan bahasa umum semacam ini tanpa penjelasan konkret di baliknya, itu tanda untuk meminta klarifikasi lebih lanjut sebelum menandatangani apa pun. Vendor yang benar-benar memahami kebutuhan Anda biasanya bisa menjelaskan dengan detail yang jauh lebih spesifik, karena mereka sudah memikirkan bagaimana sistem tersebut akan benar-benar dipakai dalam operasional sehari-hari bisnis Anda.

Bandingkan lebih dari sekadar dua proposal

Membandingkan hanya dua proposal membuat Anda rentan menganggap salah satunya sebagai patokan “normal” padahal keduanya sama-sama tidak ideal. Mengumpulkan setidaknya tiga proposal dari vendor yang berbeda memberi gambaran yang lebih jelas tentang kisaran harga yang wajar untuk ruang lingkup pekerjaan yang Anda butuhkan, sekaligus membantu mengidentifikasi proposal yang menyimpang jauh dari kewajaran — baik karena terlalu murah maupun terlalu mahal untuk cakupan yang sebenarnya setara.

Penutup

Proposal software house adalah dokumen yang perlu dibaca dengan teliti, bukan hanya dilihat angka totalnya. Dengan memeriksa ruang lingkup, hal yang sering tidak tertulis, dan cara perubahan kebutuhan ditangani, Anda bisa membandingkan penawaran secara adil dan menghindari kejutan biaya yang tidak perlu di tengah project.