8 Kesalahan Pemilik Bisnis Saat Memesan Aplikasi yang Bikin Proyek Gagal

Dua penawaran aplikasi bisa memiliki selisih harga yang besar meski deskripsi fiturnya terlihat sama. Satu vendor mungkin menganggap “modul stok” hanya berarti tambah dan ubah jumlah barang, sementara vendor lain memasukkan multi-gudang, stok minimum, retur, riwayat transaksi, dan hak akses. Jika ruang lingkup belum dijelaskan, pemilik bisnis sedang membandingkan dua asumsi, bukan dua penawaran yang setara.

1. Memulai dari fitur, bukan masalah

Permintaan “kami butuh dashboard” belum memberi tahu keputusan apa yang harus dibuat pengguna. Apakah pemilik ingin melihat barang yang hampir habis, margin per produk, pesanan terlambat, atau piutang jatuh tempo? Fitur adalah bentuk solusi. Masalah bisnis menjelaskan mengapa solusi itu perlu dibuat.

Sebelum menyusun daftar fitur, tulis kondisi sekarang, bagian yang paling menghambat, siapa yang terkena dampak, dan hasil yang ingin berubah. Discovery yang baik dimulai dari masalah, pengguna, batasan, serta biaya dari masalah itu, seperti dijelaskan dalam panduan GOV.UK tentang discovery.

2. Ruang lingkup dibiarkan terbuka

Kata “lengkap”, “otomatis”, atau “terintegrasi” bisa ditafsirkan berbeda. Tuliskan apa yang masuk dan tidak masuk dalam versi pertama. Untuk fitur integrasi, sebutkan sistem tujuan, data yang dikirim, kapan sinkronisasi terjadi, dan bagaimana kegagalan ditangani. Jika kebutuhan berubah, sepakati cara menilai dampak terhadap biaya dan jadwal.

Project Management Institute membahas scope creep sebagai penambahan fungsi di luar lingkup awal tanpa penyesuaian waktu atau biaya yang sepadan, serta menekankan pengelolaan kebutuhan sebagai salah satu cara mengendalikannya (PMI, Capturing and Specifying Project Requirements). Perubahan kebutuhan tidak selalu buruk; yang bermasalah adalah perubahan yang tidak terlihat dalam keputusan proyek.

3. Pengguna sebenarnya tidak dilibatkan

Pemilik proses belum tentu orang yang menjalankannya delapan jam sehari. Staf gudang mungkin perlu memindai barang dengan ponsel, sementara supervisor perlu menyetujui selisih dan manajer hanya melihat laporan. Jika hanya satu pihak yang menentukan alur, aplikasi dapat cocok untuk presentasi tetapi tidak sesuai pekerjaan harian.

Libatkan perwakilan setiap peran saat pemetaan proses dan uji prototipe atau versi awal dengan transaksi yang nyata. Tanyakan langkah mana yang masih membingungkan dan bagian mana yang tetap dikerjakan di luar aplikasi. Feedback harus memengaruhi keputusan, bukan sekadar dikumpulkan setelah desain selesai.

4. Memilih penawaran hanya dari harga paling rendah

Harga murah tidak otomatis buruk, sama seperti harga tinggi tidak otomatis menjamin hasil. Periksa apa yang termasuk: analisis, desain, pengujian, migrasi, dokumentasi, deployment, pelatihan, dukungan, dan biaya perubahan. Minta setiap vendor menuliskan asumsi serta pengecualian dengan format yang sama agar penawaran dapat dibandingkan.

Estimasi software memang bergantung pada banyak variabel. NASA menyarankan agar perkiraan didasarkan pada ruang lingkup dan ukuran pekerjaan serta mempertimbangkan kompleksitas, risiko, teknologi, pengujian, dan seluruh siklus hidup (NASA Software Engineering Handbook). Bila penawaran datang sangat cepat padahal proses belum dibahas, mintalah penjelasan tentang apa yang belum dihitung.

5. Tidak menetapkan kriteria penerimaan

Kalimat “fitur berjalan normal” terlalu subjektif. Untuk fungsi stok, misalnya, kriteria yang bisa diuji adalah: ketika penerimaan disimpan, jumlah stok lokasi bertambah sesuai konversi satuan; transaksi tercatat di riwayat; pengguna tanpa hak tidak bisa mengubah jumlah; dan laporan menunjukkan saldo yang sesuai. Contoh ini lebih jelas daripada sekadar meminta “modul stok selesai”.

Tentukan skenario sukses, kondisi gagal, dan siapa yang menyetujui hasil pengujian. Sisihkan waktu untuk uji penerimaan pengguna sebelum rilis. Jika kriteria baru ditulis saat aplikasi sudah jadi, perbedaan ekspektasi akan lebih sulit diselesaikan.

6. Data lama dianggap akan pindah dengan sendirinya

Migrasi bukan hanya menyalin baris ke database baru. Data mungkin memiliki kode produk ganda, nama pelanggan yang berbeda penulisannya, nilai kosong, atau satuan yang tidak konsisten. Buat pemetaan kolom, bersihkan data penting, lakukan uji migrasi, lalu cocokkan jumlah dan nilai sebelum sistem lama ditinggalkan.

Tentukan juga data historis apa yang harus dibawa. Ada bisnis yang membutuhkan seluruh riwayat transaksi; ada yang cukup memindahkan saldo pembukaan serta menyimpan arsip lama untuk referensi. Keputusan ini memengaruhi biaya dan risiko, sehingga sebaiknya dibuat sebelum estimasi final.

7. Kepemilikan akun, data, dan source code tidak jelas

Kontrak dan kesepakatan proyek perlu menjelaskan siapa yang memiliki data, akses hosting, domain, akun layanan eksternal, source code, dokumentasi, serta hak menggunakan komponen pihak ketiga. Tentukan siapa yang menyimpan kredensial produksi dan bagaimana akses diberikan atau dicabut. Jangan sampai perusahaan tidak dapat mengakses aplikasinya sendiri ketika personel atau vendor berubah.

Minta proses serah terima tertulis. Untuk sistem penting, pastikan setidaknya ada dokumentasi deployment, instruksi backup dan restore, daftar integrasi, serta prosedur pemulihan akses. Detail legal kepemilikan perlu diperiksa sesuai kontrak dan hukum yang berlaku, bukan hanya berdasarkan janji saat presentasi.

8. Tidak ada rencana setelah peluncuran

Tentukan bagaimana bug dilaporkan, apa yang termasuk garansi, jam dukungan, target respons, dan bagaimana permintaan fitur baru dihitung. Pastikan ada rencana backup, pembaruan dependensi, pemantauan, dan penanganan gangguan. “Selesai dibuat” tidak sama dengan “siap dipakai dan dirawat”.

Checklist sebelum menyetujui proyek

Sebelum tanda tangan, pastikan jawaban tertulis tersedia untuk pertanyaan berikut:

• Masalah apa yang menjadi tujuan versi pertama?
• Fitur dan integrasi apa yang termasuk serta tidak termasuk?
• Siapa yang akan menguji dan menyetujui hasilnya?
• Bagaimana perubahan ruang lingkup memengaruhi biaya dan jadwal?
• Siapa pemilik data, akun, dokumentasi, dan source code?
• Berapa biaya operasional dan dukungan setelah rilis?

Tidak semua jawaban harus rumit. Yang penting, pemilik bisnis dan vendor memahami hal yang sama. Jika kebutuhan belum cukup jelas, gunakan tahap pemetaan atau discovery terlebih dahulu. Langkah itu dapat menghindarkan bisnis dari membayar solusi besar sebelum masalahnya benar-benar dipahami.

Referensi

• GOV.UK Service Manual, How the discovery phase works
• Project Management Institute, Capturing and Specifying Project Requirements
• NASA Software Engineering Handbook, Cost Estimation

Referensi diakses 25 Oktober 2026.