Custom software vs SaaS: cara memilih yang tepat untuk perusahaan Anda
Kapan cukup berlangganan SaaS, kapan lebih hemat membangun custom software. Lima pertanyaan, contoh hitungan tiga tahun, dan jalan tengahnya.
Intinya
- Pakai SaaS untuk proses yang sama di semua perusahaan. Bangun sendiri untuk proses yang membedakan bisnis Anda.
- Bandingkan biaya dalam tiga tahun dengan jumlah pengguna yang Anda harapkan, bukan harga bulan pertama.
- Jalan tengah yang sering paling masuk akal: SaaS untuk inti yang umum, lapisan custom kecil untuk yang khas.
Pertanyaan ini muncul di hampir setiap percakapan pertama dengan klien, baik startup maupun perusahaan yang baru mulai digital: sebaiknya berlangganan aplikasi siap pakai (SaaS), atau membangun software sendiri?
Jawabannya memang tergantung, tapi memilih antara custom software vs SaaS tidak harus membingungkan. Di bawah ini cara berpikir yang kami pakai, lengkap dengan contoh hitungan dan daftar pertanyaan untuk vendor.
Jawaban singkat
Pakai SaaS untuk proses yang sama di semua perusahaan. Akuntansi, penggajian, email, penyimpanan dokumen. Tidak ada gunanya membangun ulang sesuatu yang sudah dikerjakan ribuan perusahaan dengan cara yang sama.
Bangun sendiri untuk proses yang membedakan bisnis Anda, atau proses yang tidak cocok dengan alat umum tanpa banyak jalan pintas. Contohnya cara Anda menjadwalkan produksi, cara tim lapangan melapor, atau produk yang Anda jual ke pelanggan.
Lima pertanyaan untuk memutuskan
1. Seberapa khas prosesnya?
Kalau tim harus mengubah cara kerja yang justru menjadi keunggulan Anda agar cocok dengan aplikasi, itu tanda SaaS kurang pas. Kalau perubahannya hanya soal kebiasaan, SaaS biasanya menang.
Cara mengujinya: tulis proses utama Anda dalam lima sampai tujuh langkah, lalu coba jalankan di versi uji coba aplikasi. Tandai langkah yang harus disiasati, misalnya dicatat di luar aplikasi atau dikerjakan manual. Kalau langkah yang disiasati adalah langkah yang paling penting bagi bisnis Anda, pertimbangkan custom.
2. Berapa biayanya dalam tiga tahun?
SaaS terlihat murah di bulan pertama karena dibayar per pengguna per bulan. Hitung untuk tiga tahun dengan jumlah pengguna yang Anda harapkan, bukan jumlah hari ini. Bagian berikutnya berisi contoh hitungannya.
3. Harus terhubung dengan apa saja?
Aplikasi yang tidak bisa berbicara dengan sistem lain menciptakan pekerjaan ketik ulang. Periksa apakah SaaS punya API yang terbuka dan terdokumentasi, dan apakah integrasi yang Anda butuhkan sudah ada atau harus dibangun.
4. Siapa pemilik datanya, dan bagaimana keluar?
Tanyakan bagaimana data diekspor, dalam format apa, dan berapa biayanya kalau Anda berhenti berlangganan. Untuk software custom, pastikan kode, akses, dan dokumentasi diserahkan kepada Anda, dan kepemilikannya tertulis di kontrak.
5. Siapa yang merawatnya?
SaaS dirawat penyedianya, termasuk pembaruan keamanan. Software custom butuh perawatan: pembaruan, perbaikan, dan penyesuaian ketika bisnis berubah. Kalau tidak ada anggaran atau tim untuk itu, software custom akan menua lebih cepat dari yang Anda kira.
Contoh hitungan biaya tiga tahun
Angka di bawah ini ilustrasi untuk menunjukkan cara menghitung, bukan harga pasar atau penawaran. Ganti dengan angka dari vendor Anda sendiri.
Misalkan sebuah aplikasi SaaS dihargai Rp 250.000 per pengguna per bulan. Sebagai pembanding, misalkan membangun sistem custom butuh Rp 250 juta di awal, ditambah perawatan Rp 5 juta per bulan.
| Skenario | SaaS, 3 tahun | Custom, 3 tahun |
|---|---|---|
| 40 pengguna, tetap | Rp 360 juta | Rp 430 juta |
| 40 pengguna, naik jadi 80 di tahun ketiga | Rp 480 juta | Rp 430 juta |
| 80 pengguna sejak awal | Rp 720 juta | Rp 430 juta |
Dari contoh ini terlihat polanya. Dengan jumlah pengguna yang tetap kecil, SaaS lebih hemat. Begitu jumlah pengguna tumbuh, biaya SaaS naik terus, sementara biaya custom relatif datar. Titik impasnya berbeda untuk setiap perusahaan, dan itu yang perlu Anda hitung sebelum memutuskan.
Dua hal sering terlupa dalam hitungan ini. Pertama, modul tambahan dan biaya integrasi SaaS. Kedua, waktu yang dihabiskan tim untuk menyiasati aplikasi yang tidak cocok, misalnya mengetik ulang data ke spreadsheet. Biaya kedua ini tidak muncul di tagihan, tapi nyata.
Tiga contoh, tiga jawaban
Tiga profil perusahaan rekaan berikut menunjukkan bagaimana lima pertanyaan tadi menghasilkan jawaban yang berbeda.
- Distributor dengan 15 karyawan kantor. Prosesnya umum: pesanan, faktur, stok. Jumlah pengguna tidak banyak berubah. Jawabannya SaaS, dengan perhatian khusus pada ekspor data.
- Pabrik dengan jadwal produksi yang khas. Akuntansi dan penggajian tetap SaaS. Penjadwalan produksi dan laporan shift dibangun khusus, karena di situlah cara kerja pabrik berbeda dari pabrik lain.
- Startup yang menjual aplikasi ke pelanggan. Produknya sendiri custom. Operasional internal seperti email, keuangan, dan dokumen memakai SaaS, supaya tim fokus membangun produk.
Risiko terkunci di satu penyedia, dan cara menguranginya
Terkunci di satu penyedia terjadi ketika pindah terlalu mahal, entah karena data sulit dikeluarkan, entah karena seluruh proses sudah dibangun di sekitar satu aplikasi. Risiko ini ada di SaaS maupun custom. Di SaaS, Anda terkunci pada penyedianya. Di custom, Anda bisa terkunci pada vendor yang membangunnya kalau kode dan dokumentasinya tidak diserahkan.
Tiga kebiasaan menguranginya: ekspor data secara rutin dan simpan di tempat Anda sendiri, pastikan kontrak menyebut hak Anda atas data dan kode, dan catat integrasi apa saja yang bergantung pada aplikasi tertentu.
Perbandingan ringkas
| SaaS | Custom | |
|---|---|---|
| Mulai dipakai | Hari itu juga | Beberapa minggu sampai bulan |
| Biaya awal | Rendah | Lebih tinggi |
| Biaya berjalan | Naik mengikuti jumlah pengguna | Relatif tetap, untuk perawatan |
| Kesesuaian dengan proses | Anda menyesuaikan diri | Sistem menyesuaikan diri |
| Kepemilikan | Anda menyewa | Anda memiliki, bila tertulis di kontrak |
| Risiko terbesar | Terkunci di satu penyedia | Tidak ada yang merawat |
Jalan tengah yang sering terlupakan
Pilihannya tidak harus salah satu. Pola yang sering paling masuk akal: SaaS untuk inti yang umum, lalu lapisan custom kecil di atasnya. Misalnya aplikasi akuntansi tetap dipakai, sementara formulir laporan lapangan dibangun khusus dan mengirim datanya langsung ke aplikasi akuntansi lewat integrasi. Tim lapangan mendapat alat yang cocok dengan kerjanya, dan tim keuangan tidak perlu mengetik ulang.
Jalan tengah ini hanya bisa dipakai kalau SaaS yang Anda pilih punya API yang layak. Jadi pertanyaan ketiga di atas sering menjadi penentu.
Pertanyaan untuk vendor sebelum tanda tangan
Untuk penyedia SaaS
- Bagaimana harga berubah kalau jumlah pengguna naik dua kali lipat?
- Apakah ada API, dan apa batasannya?
- Bagaimana cara mengekspor semua data, dan dalam format apa?
- Di mana data disimpan, dan apakah dipakai untuk keperluan lain? Kalau layanannya memakai AI, tujuh pertanyaan soal kebijakan AI ini juga berlaku.
Untuk vendor software custom
- Siapa pemilik kode, desain, dan akses server setelah proyek selesai?
- Dokumen apa saja yang diserahkan, dan apakah tim lain bisa melanjutkannya?
- Siapa yang menjawab laporan masalah setelah rilis, dan berapa lama waktu jawabnya?
- Bagaimana calon pengguna dilibatkan sebelum sistem dibangun?
Pertanyaan terakhir sering dianggap sepele. Padahal software custom yang tidak melibatkan penggunanya berisiko bernasib sama dengan software yang dibeli lalu tidak dipakai karyawan.
Tanda Anda salah pilih
- Tim membuat spreadsheet pendamping di samping aplikasi karena ada data yang tidak muat.
- Biaya langganan naik setiap kali tim bertambah, dan fitur yang dipakai tetap sama.
- Software custom tidak pernah diperbarui sejak rilis, dan hanya satu orang yang paham cara kerjanya.
- Ekspor data butuh tiket ke penyedia dan menunggu berhari-hari.
Pertanyaan yang sering muncul
Apakah startup sebaiknya selalu mulai dengan SaaS?
Untuk operasional internal, hampir selalu ya. Untuk produk yang Anda jual ke pelanggan, produknya sendiri adalah software custom. Yang perlu diputuskan hanyalah bagian mana yang dibangun sendiri dan bagian mana yang memakai layanan siap pakai.
Berapa lama membangun software custom yang sederhana?
Tergantung cakupan. Sistem internal dengan satu alur utama bisa mulai dipakai dalam beberapa minggu kalau cakupannya dijaga ketat. Mulailah dari satu alur yang paling sering dipakai, bukan dari daftar semua fitur.
Bagaimana kalau kami sudah terlanjur memakai SaaS yang tidak cocok?
Mulai dengan mengekspor dan merapikan data, lalu cari bagian proses yang paling sering membuat tim keluar dari aplikasi. Sering kali cukup membangun satu lapisan custom di bagian itu, tanpa pindah dari SaaS sepenuhnya.
Apakah software custom selalu lebih mahal?
Di awal, ya. Dalam tiga tahun belum tentu. Semakin banyak pengguna dan semakin khas prosesnya, semakin besar kemungkinan software custom lebih hemat. Hitung dengan angka Anda sendiri sebelum memutuskan.