Daftar pertanyaan untuk vendor aplikasi sebaiknya sudah Anda pegang sebelum rapat presentasi, bukan setelah kontrak ditandatangani. Presentasi vendor biasanya rapi: demo lancar, portofolio meyakinkan, jadwal terlihat masuk akal. Masalahnya, hal yang paling sering bikin proyek tersendat justru jarang muncul di slide.
Artikel ini berisi 21 pertanyaan untuk vendor aplikasi yang dikelompokkan menjadi tujuh bagian. Untuk tiap bagian, Anda akan menemukan alasan kenapa bagian itu penting, serta gambaran jawaban yang baik dan jawaban yang patut diwaspadai. Anda tidak perlu paham kode untuk memakainya. Yang dibutuhkan hanya kesediaan bertanya dan mencatat jawabannya.
Cara Memakai Pertanyaan untuk Vendor Aplikasi Ini
Kirim pertanyaan untuk vendor aplikasi ini secara tertulis, idealnya bersamaan dengan permintaan penawaran. Bila Anda sudah menyusun dokumen permintaan formal, masukkan saja sebagai lampiran. Panduan cara membuat RFP aplikasi membahas struktur dokumennya lebih lengkap.
Beberapa prinsip sederhana yang membantu:
- Ajukan pertanyaan yang sama ke semua vendor, supaya jawabannya bisa dibandingkan.
- Minta jawaban tertulis. Janji lisan di rapat mudah terlupa dan sulit ditagih.
- Perhatikan cara menjawab, bukan hanya isinya. Jawaban spesifik lebih berharga daripada jawaban yang terdengar indah.
- Jawaban penting sebaiknya ikut masuk ke lampiran kontrak.
1. Tim dan Cara Kerja
Aplikasi dibuat oleh orang, bukan oleh logo perusahaan. Vendor yang presentasinya bagus bisa saja menyerahkan proyek Anda ke tim junior atau subkontraktor yang tidak pernah Anda temui. Bagian ini memastikan Anda tahu siapa yang benar-benar bekerja dan bagaimana Anda dilibatkan.
- Siapa saja yang akan mengerjakan proyek ini, apa perannya, dan berapa persen waktunya dialokasikan untuk kami?
- Apakah ada bagian pekerjaan yang disubkontrakkan? Bila ya, ke siapa dan bagian mana?
- Seberapa sering kami bisa melihat progres yang bisa dicoba, bukan sekadar laporan status?
- Jawaban yang baik: menyebut nama dan peran, mengakui bila ada subkontraktor, dan menawarkan demo rutin (misalnya tiap dua minggu) di lingkungan uji.
- Patut diwaspadai: “tim kami lengkap”, tanpa nama; atau Anda baru bisa melihat aplikasi menjelang serah terima.
Tips kecil: minta vendor memperkenalkan pimpinan proyeknya langsung dalam rapat berikutnya. Dari pertanyaan untuk vendor aplikasi di bagian tim, Anda biasanya sudah bisa merasakan apakah komunikasi ke depan akan lancar atau berbelit.
2. Lingkup dan Estimasi
Sebagian besar sengketa proyek aplikasi berawal dari lingkup yang kabur. Anda mengira fitur A sudah termasuk, vendor menganggapnya permintaan tambahan. Pertanyaan di bagian ini memaksa lingkup dan cara menghitung estimasi menjadi terang.
- Fitur apa saja yang termasuk, dan apa yang secara tegas tidak termasuk?
- Bagaimana estimasi waktu dan biaya ini dihitung? Boleh kami melihat rinciannya per modul?
- Bagaimana prosedur bila ada perubahan permintaan di tengah jalan, dan bagaimana biayanya ditentukan?
- Jawaban yang baik: ada daftar “di luar lingkup”, rincian per modul, dan prosedur perubahan tertulis dengan tarif per hari kerja yang jelas.
- Patut diwaspadai: “nanti kita sesuaikan sambil jalan”, atau estimasi berupa satu angka total tanpa rincian.
Jawaban atas pertanyaan untuk vendor aplikasi soal lingkup sebaiknya dilampirkan ke kontrak sebagai spesifikasi. Dokumen inilah yang nanti menjadi acuan saat ada perbedaan pemahaman, jadi jangan puas dengan daftar fitur satu halaman.
3. Harga dan Pembayaran
Harga yang terlihat murah di awal belum tentu murah di akhir. Yang perlu Anda pahami adalah apa yang dibayar, kapan dibayar, dan biaya apa yang belum tercantum. Untuk menilai wajar tidaknya angka, gunakan parameter objektif harga aplikasi sebagai pembanding.
- Komponen apa saja yang membentuk harga ini: pengembangan, lisensi, server, pelatihan, migrasi data?
- Apakah termin pembayaran terikat pada hasil yang bisa diuji, atau pada tanggal?
- Biaya berulang apa yang akan kami tanggung setelah aplikasi berjalan?
- Jawaban yang baik: komponen dipisah, termin dikaitkan dengan milestone yang diterima (misalnya modul lulus uji penerimaan), biaya tahunan disebut terang.
- Patut diwaspadai: uang muka sangat besar tanpa milestone, atau biaya lisensi dan hosting baru muncul setelah kontrak.
Bila Anda sedang membandingkan beberapa penawaran sekaligus, panduan membedah proposal harga vendor membantu membaca angka-angka tersebut baris per baris.
Bandingkan jawaban harga dari beberapa vendor dengan pertanyaan untuk vendor aplikasi yang sama persis. Perbedaan angka sering kali bukan soal mahal atau murah, melainkan soal komponen yang dimasukkan atau dihilangkan dari penawaran.
4. Kepemilikan Source Code dan Data
Ini bagian yang paling sering dilewati, padahal dampaknya paling panjang. Bila source code dan data tidak jelas pemiliknya, Anda bisa terikat pada satu vendor bertahun-tahun. Pola kontrak yang aman dibahas di artikel klausul kontrak pencegah vendor lock-in.
- Siapa pemilik source code setelah pelunasan, dan kapan serta dalam bentuk apa source code diserahkan?
- Apakah aplikasi dibangun di atas framework atau modul milik vendor yang lisensinya tidak ikut diserahkan?
- Dalam format apa kami bisa mengekspor seluruh data kami, dan apakah ada biayanya?
- Jawaban yang baik: source code diserahkan lengkap beserta dokumentasi dan cara build; komponen milik vendor disebut terbuka; ekspor data dalam format umum seperti CSV atau dump database.
- Patut diwaspadai: “source code tetap milik kami, Anda dapat lisensi pakai” tanpa penjelasan, atau ekspor data hanya lewat permintaan berbayar.
Bila vendor ragu menjawab pertanyaan untuk vendor aplikasi di bagian kepemilikan ini, catat keraguannya. Hal ini bukan berarti vendor tersebut buruk, tetapi klausulnya perlu dinegosiasikan dengan lebih teliti sebelum Anda menandatangani apa pun.
5. Keamanan dan Kepatuhan
Bila aplikasi menyimpan data pelanggan, karyawan, atau pasien, bisnis Anda punya kewajiban hukum. UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur tanggung jawab pengendali dan prosesor data. Dalam praktiknya, vendor Anda kemungkinan besar berperan sebagai prosesor, sehingga cara mereka menjaga data ikut menjadi urusan Anda.
- Bagaimana data pribadi disimpan, dienkripsi, dan dibatasi aksesnya, termasuk akses oleh staf vendor?
- Di mana server berada, dan bagaimana prosedur backup serta pemulihannya diuji?
- Bila terjadi kebocoran data, apa langkah vendor dan berapa lama kami akan diberi tahu?
- Jawaban yang baik: menjelaskan kontrol akses, log, dan enkripsi dengan bahasa yang bisa Anda pahami; bersedia menandatangani perjanjian pemrosesan data; punya prosedur insiden tertulis.
- Patut diwaspadai: “aman, pakai HTTPS” sebagai satu-satunya jawaban, atau tidak tahu di mana backup disimpan.
Anda tidak harus menilai detail teknis keamanan sendiri. Yang penting, pertanyaan untuk vendor aplikasi di bagian ini dijawab tertulis dan cukup konkret sehingga bisa diperiksa ulang oleh orang yang paham, baik staf internal maupun auditor.
6. Garansi, SLA, dan Maintenance
Masa hidup aplikasi jauh lebih panjang daripada masa pembuatannya. Bug akan muncul, sistem operasi berubah, dan kebutuhan bisnis bergeser. Biaya di fase ini sering lebih besar dari perkiraan awal, seperti diulas di artikel kenapa biaya maintenance aplikasi tinggi.
- Berapa lama masa garansi perbaikan bug, dan apa yang dianggap bug versus permintaan baru?
- Apa isi SLA: jam layanan, waktu respons, dan waktu penyelesaian per tingkat keparahan?
- Setelah garansi habis, bagaimana skema dan dasar perhitungan biaya maintenance?
- Jawaban yang baik: definisi bug tertulis, SLA dibedakan per tingkat keparahan, biaya maintenance punya dasar hitung (misalnya kuota jam per bulan).
- Patut diwaspadai: “support 24 jam” tanpa definisi, atau biaya maintenance ditentukan “sesuai kebutuhan nanti”.
Masukkan jawaban pertanyaan untuk vendor aplikasi tentang SLA ke kontrak, lengkap dengan konsekuensinya bila tidak terpenuhi. SLA tanpa konsekuensi pada praktiknya hanya menjadi niat baik.
7. Exit Plan
Tidak ada yang suka membicarakan perpisahan di awal kerja sama. Tapi vendor bisa tutup, berganti fokus, atau hubungan kerja memburuk. Exit plan yang jelas justru membuat kedua pihak lebih tenang bekerja.
- Bila kontrak berakhir atau diputus, apa saja yang diserahkan dan dalam berapa hari?
- Apakah vendor bersedia membantu transisi ke tim atau vendor lain, dan dengan biaya berapa?
- Apa yang terjadi pada akun server, domain, dan layanan pihak ketiga: atas nama siapa semuanya didaftarkan?
- Jawaban yang baik: ada daftar serah terima, masa transisi tertentu (misalnya 30 hari), dan akun-akun penting atas nama perusahaan Anda sejak awal.
- Patut diwaspadai: domain dan server terdaftar atas nama vendor, atau vendor enggan membahas topik ini sama sekali.
Pertanyaan untuk vendor aplikasi tentang exit plan sering dianggap pesimistis. Padahal vendor yang percaya diri dengan layanannya biasanya santai saja membahasnya, karena mereka tidak mengandalkan ketergantungan untuk mempertahankan klien.
Ringkasan: Sinyal Baik vs Sinyal Waspada
Tabel berikut merangkum pola jawaban dari ketujuh kelompok pertanyaan untuk vendor aplikasi di atas. Gunakan sebagai lembar cepat saat membaca proposal.
| Kelompok | Sinyal baik | Sinyal waspada |
|---|---|---|
| Tim & cara kerja | Nama dan peran jelas, demo rutin | Tim anonim, progres tak terlihat |
| Lingkup & estimasi | Rincian per modul, prosedur perubahan | Satu angka total, “sambil jalan” |
| Harga & pembayaran | Termin berbasis milestone | Biaya tersembunyi muncul belakangan |
| Source code & data | Diserahkan lengkap, ekspor terbuka | Hanya lisensi pakai |
| Keamanan & kepatuhan | Kontrol akses dan prosedur insiden tertulis | “Aman, pakai HTTPS” |
| Garansi, SLA, maintenance | Definisi bug dan SLA per keparahan | “Support 24 jam” tanpa definisi |
| Exit plan | Daftar serah terima, akun atas nama Anda | Domain dan server atas nama vendor |
Setelah Jawaban Terkumpul: Minta Pihak Independen Membacanya
Mengajukan pertanyaan untuk vendor aplikasi baru separuh pekerjaan. Separuh lainnya adalah menilai jawabannya. Di sinilah banyak pemilik bisnis kesulitan: jawaban teknis terdengar meyakinkan, padahal ada celah yang baru terasa setahun kemudian.
Pihak independen yang paham teknis sekaligus kontrak bisa membaca jawaban vendor dengan kacamata berbeda. Layanan Bedah Proposal Vendor di NusaIT dibuat untuk ini: kami meninjau hingga tiga proposal, membandingkan jawabannya, dan menandai hal yang perlu dinegosiasikan. Detail paketnya ada di halaman konsultasi memilih vendor aplikasi.
Satu catatan keterbukaan: NusaIT juga mengembangkan aplikasi. Rekomendasi kami tidak mensyaratkan Anda memakai NusaIT sebagai vendor. Bila kami ikut diminta mengajukan penawaran untuk proyek yang sama, hal itu kami sampaikan sejak awal.
Pertanyaan yang Sering Diajukan
Apakah semua pertanyaan untuk vendor aplikasi ini wajib diajukan?
Untuk proyek kecil, Anda bisa memprioritaskan bagian kepemilikan source code, harga, dan exit plan. Namun bila aplikasi menyimpan data pribadi atau menjadi tulang punggung operasional, sebaiknya ke-21 pertanyaan diajukan semuanya.
Bagaimana jika vendor menolak menjawab secara tertulis?
Itu sendiri sudah menjadi informasi. Vendor yang serius umumnya tidak keberatan menuliskan komitmennya. Bila hanya mau menjawab lisan, minta setidaknya notulen rapat yang disetujui kedua pihak.
Kapan waktu terbaik mengajukan pertanyaan ini?
Sebelum atau bersamaan dengan permintaan proposal. Dengan begitu, jawabannya ikut membentuk harga dan lingkup, bukan menjadi bahan renegosiasi setelah angka disepakati.
Apakah jawaban yang bagus menjamin vendornya bagus?
Tidak otomatis. Jawaban yang baik perlu dicek ke portofolio, referensi klien yang bisa dihubungi, dan terutama dimasukkan ke kontrak. Jawaban yang tidak tertuang di kontrak sulit ditagih.
Siapa di internal yang sebaiknya ikut menilai jawaban vendor?
Idealnya pemilik proses bisnis, bagian keuangan, dan orang yang paham teknis. Bila tidak ada staf teknis, pertanyaan untuk vendor aplikasi tetap bisa diajukan, lalu jawabannya ditinjau oleh konsultan independen.
