Bahasa Indonesia

Pohon Keputusan Pembelian SaaS: Kapan Membeli, Membangun, atau Menambahkan

Fakta Utama: Keputusan Pembelian SaaS di Perusahaan Mid-Market

  • Rata-rata durasi evaluasi SaaS: 84 hari dari demo pertama hingga kontrak ditandatangani untuk kesepakatan di atas $25 ribu per tahun (Gartner, benchmarks pembelian B2B 2025).
  • Vendor yang masuk daftar pendek per kesepakatan: 3 hingga 5 untuk kesepakatan mid-market umum; kesepakatan enterprise rata-rata 6 hingga 8 (Forrester SaaS buying pulse).
  • Pengambil keputusan per kesepakatan: rata-rata 6,8 orang dalam pembelian perangkat lunak B2B mid-market, naik dari 5,4 pada tahun 2020 (Gartner B2B Buying Journey).
  • Win-rate untuk keputusan terstruktur vs ad-hoc: tim yang menggunakan kerangka keputusan terdokumentasi melaporkan tingkat adopsi alat 2,3x lebih tinggi satu tahun setelah pembelian dibandingkan tim yang melewati langkah-langkah kerangka (McKinsey software buying study).
  • Tumpang tindih alat di perusahaan mid-market: 30-40% alat SaaS memiliki tumpang tindih fitur dengan setidaknya satu alat lain dalam tumpukan (Productiv State of SaaS).

COO tersebut memiliki masalah: sebenarnya tiga masalah. Dalam satu kuartal, tiga tim terpisah masing-masing mendatangi pimpinan dengan permintaan "kami hanya butuh sesuatu yang cepat". Ketiga permintaan itu disetujui. Ketiganya membeli. Dan ketika IT lead memetakan tumpukan empat bulan kemudian, dua alat memiliki tumpang tindih fitur yang signifikan satu sama lain, dan satu menduplikasi fungsionalitas yang sudah dimiliki perusahaan dalam platform yang dilisensikan delapan belas bulan sebelumnya.

Tidak ada yang melakukan kesalahan, sebenarnya. Setiap tim memiliki kebutuhan nyata dan menemukan solusi nyata. Namun tidak ada yang mengajukan pertanyaan sebelumnya: apakah kita perlu membeli apa pun?

Pertanyaan itu (beli, bangun, atau tambahkan) terdengar jelas. Kenyataannya tidak. Sebagian besar perusahaan melewatinya sama sekali karena memerlukan pekerjaan sebelum percakapan vendor dimulai, dan percakapan vendor lebih mudah. Demo sudah dijadwalkan. Trial sudah berjalan. Keputusan pembelian terjadi sebelum kerangka keputusan pernah diterapkan.

Panduan ini memberikan kerangka tersebut. Panduan ini dirancang untuk perusahaan dengan 50 hingga 500 orang yang membuat keputusan SaaS cukup cepat sehingga proses pengadaan formal terasa berlebihan, namun cukup lambat sehingga SaaS sprawl memiliki konsekuensi nyata terhadap anggaran dan produktivitas.

Mengapa Jawaban Default Selalu "Beli"

Pasar SaaS telah merancang jalur yang paling mudah agar langsung mengarah pada pembelian. Free trial menghilangkan hambatan. Product-led growth berarti alat menyebar di dalam organisasi sebelum pengadaan pernah mendengarnya. Menurut penelitian Gartner tentang perilaku pembelian perangkat lunak, pengguna akhir kini memulai lebih dari 60% pembelian perangkat lunak, sering kali melewati IT dan pengadaan sepenuhnya. Presentasi vendor AI pada tahun 2025 dan 2026 menambahkan kerumitan baru: setiap kemampuan terlihat seperti platform, dan setiap platform berjanji menggantikan tiga alat yang sudah Anda miliki. Sebelum mengevaluasi vendor apa pun, ada baiknya memahami cara menjalankan RFP SaaS yang tidak membuang enam minggu, karena proses RFP mengasumsikan Anda sudah memutuskan untuk membeli.

Jawaban default adalah "beli" karena itu adalah jawaban yang paling mudah dipertahankan. Anda bisa menampilkan demo. Anda bisa menunjuk ke case study. Anda bisa membuat tim produktif dalam dua minggu. Membangun membutuhkan berbulan-bulan, dan menambahkan membutuhkan seseorang yang memahami alat yang ada dengan cukup baik untuk mengetahui apa yang sebenarnya bisa dilakukannya.

Namun biaya selalu menjawab "beli" bertambah. Jumlah alat bertumbuh. Kontrak diperpanjang otomatis. Jumlah seat bergeser. Penelitian McKinsey tentang pengeluaran perangkat lunak menunjukkan bahwa organisasi secara konsisten meremehkan total biaya perangkat lunak sebesar 30-50% ketika mereka hanya memodelkan biaya lisensi. Dan akhirnya CFO melihat lini SaaS yang tumbuh 40% year-over-year tanpa cerita yang jelas tentang apa yang dibeli. Konsekuensi hilir dari melewati langkah ini terlihat dalam masalah SaaS sprawl, sebuah pola yang muncul di hampir setiap perusahaan mid-market yang tumbuh cepat.

Kerangka keputusan mengubah titik awal dari "vendor mana?" menjadi "apakah kita perlu membeli sama sekali?"

Pohon Keputusan Empat Cabang

Pohon Keputusan Build-vs-Buy-vs-Adopt

Pohon Keputusan Build-vs-Buy-vs-Adopt adalah kerangka tiga cabang yang memaksa pertanyaan terstruktur sebelum percakapan vendor apa pun dimulai: build (bangun secara internal ketika fungsi tersebut inti untuk keunggulan kompetitif), buy (lisensi alat SaaS yang dibuat khusus ketika fungsi tersebut non-inti dan pasar vendor sudah matang), atau adopt (perluas kemampuan yang sudah dimiliki dalam tumpukan yang ada ketika cakupannya 70% atau lebih). Pohon ini berjalan secara berurutan: inti vs non-inti terlebih dahulu, kemudian biaya bangun, kemudian audit tumpukan yang ada, kemudian kematangan pasar vendor, dan berhenti pada cabang pertama yang menghasilkan jawaban yang dapat dipertahankan.

Berikut kerangkanya. Telusuri setiap cabang secara berurutan. Cabang pertama yang memberikan jawaban jelas adalah tempat Anda berhenti.

Cabang 1: Apakah Ini Fungsi Inti atau Non-Inti?

Fungsi inti adalah hal-hal yang dilakukan bisnis Anda yang membedakan Anda atau langsung menghasilkan pendapatan. Fungsi non-inti adalah kegiatan pendukung: hal-hal yang dibutuhkan setiap bisnis tetapi bukan sumber keunggulan kompetitif. Kerangka build vs. buy dari Harvard Business Review membingkai perbedaan ini di sekitar kontrol strategis: alihkan apa yang bersifat komoditas, miliki apa yang bersifat proprietary.

Untuk sebagian besar perusahaan mid-market, contohnya terlihat seperti ini:

Inti: Cara Anda menjual, cara Anda memberikan layanan, cara Anda mempertahankan pelanggan, cara produk Anda bekerja.

Non-inti: Manajemen pengeluaran, penjadwalan, penyimpanan file, administrasi HR, IT ticketing.

Jika kebutuhannya benar-benar inti, opsi membangun layak dipertimbangkan secara serius. Bukan karena membangun selalu lebih baik, tetapi karena mengalihdayakan hal yang membedakan Anda membawa risiko strategis yang tidak tercermin dalam harga stiker.

Jika kebutuhannya non-inti, jangan membangun. Lanjutkan ke Cabang 2.

Cabang 2: Seperti Apa Biaya Membangun Sebenarnya?

Sebagian besar perusahaan tidak membuat estimasi biaya nyata sebelum menolak opsi membangun. Estimasinya adalah "kami harus merekrut insinyur" dan percakapan berlanjut. Itu adalah jawaban yang tepat untuk sebagian besar fungsi non-inti, tetapi untuk fungsi inti layak mendapat angka nyata.

Lembar kerja biaya membangun dasar terlihat seperti ini:

Kategori Biaya Metode Estimasi
Pengembangan awal Jam kerja insinyur x tarif per jam
Pemeliharaan berkelanjutan 15-20% dari biaya bangun awal per tahun
Keamanan dan kepatuhan Kepatuhan OWASP, pen test, patching berkelanjutan
Hosting dan infrastruktur Estimasi biaya cloud pada skala target
Dokumentasi dan pelatihan Sering 20-30% dari waktu pengembangan
Biaya peluang Apa lagi yang bisa dibangun tim ini?

Baris terakhir adalah yang secara konsisten diremehkan perusahaan. Jika insinyur Anda bisa membangun fitur produk alih-alih alat internal, biaya sebenarnya dari membangun termasuk pendapatan yang tidak Anda hasilkan.

Jika biaya membangun secara signifikan lebih tinggi dari alternatif SaaS selama cakrawala 3 tahun (yang biasanya terjadi untuk fungsi non-inti), lanjutkan ke Cabang 3. Kerangka pemodelan TCO untuk SaaS mencakup model biaya lima kategori ini secara detail, termasuk biaya implementasi, integrasi, dan keluar yang tidak ditemukan dalam perbandingan lisensi sederhana.

Cabang 3: Bisakah Alat yang Ada Melakukan Ini?

Sebelum membeli apa pun yang baru, audit apa yang Anda miliki. Ini adalah langkah yang paling sering dilewati perusahaan karena membutuhkan seseorang untuk benar-benar masuk ke alat yang ada dan memahami apa yang bisa mereka lakukan.

Pertanyaan yang perlu diajukan:

  • Apakah platform saat ini memiliki fitur ini secara native atau melalui konfigurasi?
  • Apakah platform saat ini memiliki fitur ini dalam roadmap (dalam 90 hari)?
  • Apakah ada integrasi atau otomasi antara dua alat yang ada yang mendekati kebutuhan ini?
  • Apakah ada seat yang kurang dimanfaatkan dalam alat saat ini yang memiliki kemampuan ini?

Audit ini seharusnya membutuhkan satu orang selama satu hingga dua hari, bukan enam minggu. Anda mencari kemampuan yang ada yang cukup dekat, bukan kecocokan sempurna.

Scorecard kompleksitas integrasi di bawah ini membantu Anda menilai apakah menambahkan ke alat yang ada benar-benar lebih sederhana atau hanya menukar satu jenis pekerjaan dengan yang lain:

Faktor Kompleksitas Rendah Kompleksitas Menengah Kompleksitas Tinggi
Keselarasan model data Objek sama, field sama Objek berbeda, pemetaan bersih Objek berbeda, pemetaan kustom diperlukan
Ketersediaan API Integrasi native tersedia REST API tersedia, tidak ada integrasi native Hanya webhook atau tidak ada API
Beban pemeliharaan Set-and-forget Tinjauan bulanan diperlukan Rekayasa berkelanjutan diperlukan
Perubahan alur kerja pengguna Alur kerja sama, tombol baru Titik masuk berbeda, hasil sama Alur kerja baru diperlukan

Jika dua kategori atau lebih mendapat skor "Tinggi," penambahan kemungkinan lebih mahal dalam praktiknya daripada membeli alat yang dibuat khusus.

Jika tumpukan yang ada memiliki kemampuan yang cukup dekat, gunakan alat tersebut. Jika tidak, lanjutkan ke Cabang 4.

Cabang 4: Apakah Pasar Vendor Sudah Matang?

Kematangan pasar vendor penting karena menentukan risiko jangka panjang Anda. Analisis pasar SaaS Forrester membedakan antara pemimpin kategori dengan rekam jejak 5+ tahun dan penantang baru yang masih dalam siklus product-market fit, perbedaan yang secara langsung mempengaruhi cara Anda menetapkan ukuran komitmen kontrak. Membeli di pasar yang matang berarti Anda memiliki:

  • Beberapa vendor mapan dengan rekam jejak 5+ tahun
  • Diferensiasi fitur yang jelas (bukan hanya diferensiasi pemasaran)
  • Pelanggan referensi di industri dan rentang ukuran Anda
  • Ketentuan kontrak standar dengan poin negosiasi yang diketahui

Membeli di pasar yang belum matang, terutama dalam gelombang SaaS AI saat ini, berarti:

  • Vendor berusia 12-18 bulan dengan pendanaan seed atau Series A
  • Roadmap fitur besar, kemampuan produksi sempit
  • Penetapan harga bersifat eksperimental dan akan berubah
  • Pelanggan referensi adalah early adopter yang dipilih sendiri

Ini tidak berarti Anda tidak boleh membeli dari vendor baru. Ini berarti Anda harus menyesuaikan komitmen dengan kematangan pasar. Pilot $500/tahun adalah risiko yang berbeda dari kontrak tahunan $50 ribu dengan auto-renewal 2 tahun.

Aturan keputusan: Jika pasar sudah matang, beli dengan due diligence standar. Jika belum matang, beli dengan komitmen terbatas (tahunan, bukan multi-tahun; lingkup Pilot, bukan rollout penuh) dan bangun pemicu penilaian ulang ke dalam kontrak. Untuk alat yang menggunakan AI secara native, mengevaluasi SaaS yang diaktifkan AI membantu memisahkan kemampuan nyata dari klaim pemasaran sebelum Anda membuat komitmen multi-tahun.

Jebakan Umum di Setiap Cabang

Solusi Titik yang Menduplikasi Seat yang Ada

Kesalahan paling umum dan mahal. Tim membeli alat manajemen proyek karena mereka tidak menyukai cara alat manajemen proyek perusahaan yang ada dikonfigurasi. Solusinya bukan alat baru. Solusinya adalah percakapan konfigurasi yang lebih baik atau pelatihan pada alat yang ada.

Sebelum menyetujui pembelian baru apa pun, minta pemohon mendokumentasikan apakah alat yang ada sudah mencakup 70% atau lebih dari kebutuhan.

Membangun Apa yang Bisa Dibeli Seharga $200/Bulan

Waktu rekayasa mahal. Seorang insinyur senior menghabiskan $150-200/jam. Jika alat SaaS tersedia seharga $200/bulan, opsi membangun perlu memberikan setidaknya $7.200 nilai tahunan di atas apa yang disediakan alat SaaS hanya untuk mencapai titik impas pada 30 jam pengembangan pertama. Jarang terjadi.

Pengecualian: ketika solusi SaaS yang ada menciptakan masalah privasi data, kepatuhan, atau keamanan yang dihindari oleh alat internal. Itu dihitung secara berbeda.

Logika Penambahan yang Menciptakan Silo Data

Memperluas alat yang ada terdengar rendah hambatan sampai Anda menyadari bahwa integrasi menciptakan aliran data yang hidup di tiga sistem dan hanya dipahami oleh satu orang. Ketika orang itu pergi, integrasi rusak dan tidak ada yang tahu mengapa.

Sebelum menyetujui penambahan, dokumentasikan aliran data, tetapkan pemilik, dan konfirmasi bahwa integrasi dapat dibangun ulang hanya dari dokumentasi.

Membuat Keputusan Bertahan

Kerangka keputusan hanya berfungsi jika diterapkan sebelum kalender demo penuh. Cara praktis untuk menerapkan ini:

  1. Wajibkan brief satu halaman sebelum evaluasi vendor apa pun dimulai. Brief menjawab: masalah apa yang kami selesaikan, cabang pohon keputusan mana yang kami telusuri, dan mengapa kami memilih "beli"?

  2. Jadikan IT lead atau pemilik SaaS yang ditunjuk sebagai bagian dari Cabang 3 setiap saat. Mereka mengenal tumpukan. Pemohon tidak selalu.

  3. Tetapkan pemicu tinjauan untuk pembelian apa pun di atas $10 ribu/tahun. Satu tahun kemudian, seseorang memeriksa apakah alat digunakan, apakah menduplikasi sesuatu yang lain, dan apakah kebutuhan asli masih ada.

  4. Lacak alat yang dinonaktifkan sebagai metrik keberhasilan. Jika Anda hanya mengukur akuisisi alat baru, Anda hanya mengukur setengah dari masalahnya.

Mengukur Apakah Kerangka Berfungsi

Anda akan tahu kerangka keputusan berfungsi ketika:

  • Tumpang tindih alat berkurang pada audit tumpukan tahunan
  • Waktu pengambilan keputusan untuk pembelian perangkat lunak berkurang (karena kerangka mengurangi deliberasi berputar)
  • Anggaran yang dipulihkan dari alat yang dinonaktifkan atau dikonsolidasikan muncul sebagai baris dalam tinjauan tahunan
  • Tiket IT terkait kebingungan alat atau hambatan alat duplikat berkurang

Tujuannya bukan memperlambat keputusan perangkat lunak. Tujuannya adalah menempatkan dua puluh menit pemikiran terstruktur di awal yang mencegah empat bulan pembersihan.

Bagaimana Rework Mendukung Pohon Keputusan dalam Praktiknya

Kerangka hanya berfungsi jika brief satu halaman, audit tumpukan Cabang 3, dan persetujuan IT lead terjadi sebelum demo vendor, dan di situlah sebagian besar tim mid-market gagal. Rework Work Ops (mulai dari $6/user/bulan) memberi pemilik SaaS satu tempat untuk mendokumentasikan setiap jalannya pohon keputusan, pernyataan masalah, cabang mana yang menghasilkan jawaban, hasil audit alat yang ada, dan pemberi persetujuan, serta merutekannya melalui pemangku kepentingan yang tepat tanpa mengejar orang melalui Slack.

Template Work Ops memungkinkan Anda menstandarisasi brief satu halaman sehingga setiap permintaan alat baru mengikuti struktur yang sama, dan perutean alur kerja mengirimkan tinjauan Cabang 3 langsung ke IT lead atau pemilik SaaS yang ditunjuk dengan hard stop hingga mereka menyetujui. Karena Work Ops berada di samping Rework CRM/Sales Ops (mulai dari $12/user/bulan), keputusan alat komersial yang menyentuh tim pendapatan mendapatkan tinjauan terstruktur yang sama dengan alat operasi, tanpa alur kerja terpisah, tanpa alat terpisah. Pemicu tinjauan 12 bulan untuk pembelian di atas $10 ribu/tahun dapat dijadwalkan sebagai tugas berulang yang terikat pada catatan keputusan asli, sehingga tidak ada yang diperpanjang otomatis tanpa manusia memeriksa apakah masih digunakan.

Pelajari Lebih Lanjut

Pertanyaan yang Sering Diajukan Tentang Pohon Keputusan Pembelian SaaS

Kapan perusahaan mid-market harus membangun alih-alih membeli SaaS?

Bangun ketika fungsi tersebut benar-benar inti, artinya membedakan produk Anda, langsung mendorong pendapatan, atau menciptakan data proprietary yang tidak dapat direplikasi pesaing. Fungsi non-inti (administrasi HR, laporan pengeluaran, penjadwalan, penyimpanan file) hampir tidak pernah lulus uji TCO 3 tahun dibandingkan membeli. Uji sebenarnya: jika Anda mengalihdayakan kemampuan ini ke vendor, apakah posisi kompetitif Anda akan melemah? Jika tidak, jangan membangun.

Bagaimana cara mengetahui apakah alat yang ada sudah menyelesaikan masalah saya?

Jalankan audit 1-2 hari sebelum menyetujui pembelian baru. Periksa apakah platform saat ini mencakup kebutuhan secara native, melalui konfigurasi, melalui item roadmap 90 hari, atau melalui integrasi dengan alat yang dimiliki. Ambang batasnya adalah cakupan 70%, Anda mencari "cukup dekat," bukan "kecocokan sempurna." Minta pemohon mendokumentasikan hasil audit dalam brief satu halaman sebelum demo dijadwalkan.

Siapa yang seharusnya ada dalam keputusan pembelian SaaS?

Data Gartner menunjukkan rata-rata 6,8 pengambil keputusan per kesepakatan perangkat lunak B2B mid-market. Peran yang tidak dapat ditiadakan: pemimpin tim pemohon (memiliki masalah), IT lead atau pemilik SaaS yang ditunjuk (memiliki Cabang 3, yaitu audit tumpukan yang ada), keuangan (memiliki TCO dan pelacakan perpanjangan), dan sponsor eksekutif untuk pembelian di atas $25 ribu/tahun. Tinjauan keamanan dan hukum dilampirkan untuk alat yang menangani PII atau data pelanggan.

Apa kesalahan terbesar dalam pengambilan keputusan SaaS?

Melewati Cabang 3, yaitu audit tumpukan yang ada. Tim secara default memilih "beli" karena demo sudah dijadwalkan, dan tidak ada yang memeriksa apakah alat yang ada sudah mencakup kebutuhan. Penelitian Productiv menunjukkan 30-40% alat SaaS di perusahaan mid-market memiliki tumpang tindih fitur dengan sesuatu yang lain yang sudah ada dalam tumpukan. Solusinya adalah aturan prosedural yang ketat: tidak ada pembelian SaaS baru yang disetujui tanpa audit terdokumentasi dari tumpukan saat ini yang ditandatangani oleh IT lead.

Kapan 'adopt' (gunakan yang sudah ada dalam tumpukan) lebih baik dari 'buy'?

Gunakan ketika alat yang ada mencakup 70%+ kebutuhan, integrasi atau penambahan mendapat skor rendah hingga menengah pada scorecard kompleksitas (keselarasan model data, ketersediaan API, beban pemeliharaan, perubahan alur kerja), dan Anda memiliki pemilik yang dapat mendokumentasikan aliran data. Adopt lebih buruk dari buy ketika penambahan menciptakan silo data yang hanya dipahami oleh satu orang, ketika mereka pergi, integrasi rusak dan tidak ada yang tahu mengapa.

Berapa lama keputusan SaaS harus diambil?

Untuk kesepakatan di bawah $10 ribu/tahun, 2-3 minggu wajar: brief pohon keputusan, audit Cabang 3, 1-2 demo vendor, pemeriksaan referensi, tinjauan kontrak. Untuk kesepakatan $10 ribu-$50 ribu/tahun, 4-6 minggu. Untuk kesepakatan di atas $50 ribu/tahun atau komitmen multi-tahun, 8-12 minggu dengan RFP formal dan tinjauan keamanan. Tolok ukur Gartner sebesar 84 hari mencerminkan rata-rata untuk kesepakatan $25 ribu+/tahun. Jika Anda membutuhkan waktu jauh lebih lama, deliberasi berputar menghabiskan lebih banyak biaya dari alat itu sendiri.