Cara Konsultan AI Menentukan Lingkup Penggantian SaaS Internal

Setiap konsultan yang sepadan dengan tarif harian mereka menentukan lingkup penggantian SaaS internal dengan cara yang sama: membagi setiap alat menjadi bagian yang bisa Anda lihat dan bagian yang harus tepat setiap saat. SaaS (perangkat lunak yang Anda sewa setiap bulan) sebagian besar terdiri dari layar, alur kerja, dan laporan yang berada di atas inti pencatatan data yang lebih kecil. AI telah membuat paruh pertama murah untuk dibangun kembali. Paruh kedua adalah tempat proyek penggantian mati, dan cakupan lingkup yang baik dibuat untuk mengukur seberapa banyak biaya langganan Anda yang sebenarnya berada di sana.

Berikut adalah cara cakupan penggantian SaaS internal dirumuskan, langkah demi langkah, serta satu pertanyaan yang menentukan sebagian besar darinya. (Nama vendor dan angka survei di bawah ini akurat pada saat publikasi; anggap rincian ini sebagai gambaran sesaat.)

Apa yang sebenarnya terkandung dalam lingkup penggantian SaaS?

Inventarisasi tugas, bukan daftar fitur. Konsultan mencatat setiap tugas yang dilakukan alat tersebut, siapa yang menangani masing-masing tugas, dan apa yang terjadi jika hasilnya salah. Rantai persetujuan, dasbor, dan formulir masuk ke satu kolom. Pergerakan uang, penghitungan stok, pajak, dan catatan karyawan masuk ke kolom lain. Hasil kerjanya adalah pemetaan tersebut, tingkatan risiko per tugas, dan daftar setiap sistem yang terhubung secara diam-diam dengan alat tersebut.

Pertanyaan pemeringkatan adalah inti utamanya: jika hasil ini salah, bagaimana Anda akan mengetahuinya, dan berapa biayanya? Dasbor yang tidak mutakhir dapat diketahui secara sekilas dan tidak membutuhkan biaya. Total pembayaran yang salah baru terdeteksi saat musim pajak dan menelan biaya nyata.

Mengapa membagi produk menjadi dua lapisan?

Karena AI telah menekan biaya satu lapisan dan membiarkan lapisan lainnya tidak tersentuh. Lapisan antarmuka (formulir, dasbor, alat internal, alur kerja persetujuan) kini cepat dibangun kembali; model saat ini dapat menghasilkan aplikasi web yang berfungsi dalam hitungan jam, persis seperti yang kami temukan saat menanyakan apakah GPT-5.6 dapat membangun POS yang berfungsi. Lapisan infrastruktur berbeda: pemrosesan pembayaran, kepatuhan PCI (aturan keamanan kartu yang diterapkan pemroses pembayaran), inventaris saat transaksi bersamaan (dua kasir menjual unit terakhir yang sama), dan laporan yang terrekonsiliasi (total yang sesuai dengan setoran bank Anda). Lapisan tersebut rumit bukan karena kodenya panjang. Melainkan rumit karena hasil yang 'hampir benar' tidak ada nilainya di sana, dan membuktikan kebenarannya membutuhkan biaya lebih mahal daripada menghasilkan kodenya.

Model yang lebih baik pun tidak menghilangkan kendala tersebut. Hambatan utamanya adalah verifikasi dan liabilitas, bukan pembuatan kode, sehingga penentuan lingkup yang jujur memperhitungkan biaya verifikasi. Pembuatan kode hanyalah demo. Verifikasi adalah tagihannya.

Apa yang sebenarnya dibuktikan oleh penggantian SaaS Klarna?

Kisah paling gaung tentang "kami mengganti SaaS kami dengan AI" sebenarnya adalah pelajaran penentuan lingkup. Pada akhir tahun 2024, CEO Klarna mengumumkan bahwa perusahaan menghentikan penggunaan Salesforce dan Workday sebagai bagian dari perombakan AI, dan tajuk berita melaporkan bahwa AI menggantikan SaaS secara penuh. Laporan lanjutan menemukan hal yang lebih spesifik: Klarna memindahkan SDM ke vendor lain dan memenuhi kebutuhan CRM-nya dengan campuran alat alternatif dan penghubung internal, dengan AI yang ditambahkan di atasnya¹. Sebuah bank berlisensi yang menjalankan salah satu program AI paling agresif di bidang fintech tetap mempertahankan system of record-nya (salinan otoritatif data bisnis Anda) di platform yang teruji dan membangun kembali di bagian tepinya.

Itu bukanlah bentuk keraguan. Itu adalah bukti bahwa penentuan lingkup tersebut berhasil.

Angka mana yang membenarkan proyek penggantian?

Pangkas pemborosan terlebih dahulu, baru bangun kemudian. SaaS Management Index 2026 dari Zylo, yang diambil dari lebih dari 40 juta lisensi yang dikelola, menempatkan nilai tengah pengeluaran SaaS sebesar $9.455 per karyawan per tahun, menemukan rata-rata 36% lisensi tidak terpakai, dan menunjukkan unit bisnis mengendalikan 81% pengeluaran SaaS sementara IT mengelola 15% secara langsung². Seorang konsultan akan membandingkan susunan teknologi Anda dengan angka-angka tersebut sebelum mengusulkan apa pun: batalkan lisensi yang tidak terpakai, konsolidasikan alat yang tumpang tindih, dan baru setelah itu pilih kandidat yang akan dibangun kembali.

Alat-alat yang masuk ke dalam daftar pilihan memiliki profil yang serupa: biaya berulang yang tinggi, tugas yang sebagian besar berada di lapisan antarmuka, dan dampak kerusakan yang kecil jika terjadi masalah. Proyek disetujui ketika pengeluaran langganan tumbuh lebih cepat daripada biaya pembangunan dan pemeliharaan, dan setiap tugas yang wajib tepat dapat tetap berada di infrastruktur yang sudah dioperasikan oleh pihak lain.

Di manakah posisi POS dalam penentuan lingkup ini?

Di bagian spektrum yang paling tak kenal ampun. Point of sale terlihat seperti proyek antarmuka, kisi-kisi tombol dan keranjang belanja, sehingga para pemilik bisnis mengira penentuan lingkupnya sama seperti dasbor. Rasionalitasnya justru sebaliknya. Layar checkout hanyalah sebagian kecil dari produk; sisanya adalah pembayaran, perangkat keras transaksi kartu langsung yang tersertifikasi, inventaris yang tetap akurat saat dua kasir berjualan bersamaan, aturan pajak, dan laporan akhir hari yang terrekonsiliasi. Ketika POS melakukan kesalahan, kesalahan itu berkaitan langsung dengan uang, setiap hari.

Jadi konsultan menentukan lingkup pembangunan kembali POS seperti Klarna menentukan lingkup buku besarnya: antarmuka khusus, infrastruktur teruji. Pembagian tersebut dulunya membutuhkan tim pengembang. Kini hal itu menjadi sebuah kategori produk: Build dari Final mengubah perintah bahasa sehari-hari menjadi alur checkout yang dapat Anda pratinjau dan terapkan, dan Anda dapat menghubungkan AI Anda sendiri melalui MCP untuk membangun di atas infrastruktur perdagangan yang sama. Pembayaran, inventaris, pelaporan, dan perangkat keras tetap berada pada lapisan yang sudah terverifikasi.

Lantas, bagaimana seharusnya Anda menentukan lingkup penggantian SaaS internal?

Bagi setiap alat menjadi dua lapisannya, nilai setiap tugas berdasarkan biaya akibat kesalahan output yang tidak terdeteksi, dan perhitungkan biaya verifikasi daripada kodenya. Bangun kembali antarmuka dan alur kerja secara bebas; biarkan system of record tetap berada di infrastruktur yang keakuratannya dijaga oleh pihak lain. Sebelum Anda membangun kembali alat apa pun secara internal, tanyakan: jika hasilnya salah, seberapa cepat saya akan mengetahuinya? Jika jawabannya "tidak cepat," tugas tersebut sebaiknya tetap berada di sistem yang teruji.

Dan jika bagian perdagangan dari susunan teknologi Anda adalah bagian yang ingin Anda bangun kembali, mulailah dengan melihat secara jujur apa yang dapat dan tidak dapat dibangun oleh model saat ini secara mandiri: Claude vs ChatGPT vs Gemini dalam pembangunan POS nyata, atau dua jalur tanpa kode dalam cara menggunakan Gemini 3.6 Flash untuk membangun POS kustom.