Saat perusahaan membeli perangkat lunak atau layanan digitalisasi, dalam dokumen tender masih sering ditemukan ketentuan seperti “peserta tender diwajibkan menyiapkan XX orang insinyur senior, dengan waktu penempatan di lokasi tidak kurang dari XX orang-bulan”. Formulir penilaian memberikan skor berdasarkan bobot jumlah personel, kualifikasi, dan harga satuan—metode ini masih masuk akal sepuluh tahun lalu, namunAgensi cerdas dan pengiriman yang dibantu AIDi era yang sudah umum seperti sekarang, justru mudah untuk memilih pemasok yang “paling ramai” daripada yang “hasilnya paling jelas”.
Latar belakang kebijakan: Logika pengadaan sedang berubah
Dalam “Rencana Pelaksanaan Tindakan Khusus ‘Kecerdasan Buatan + Perangkat Lunak’” yang diterbitkan oleh Kementerian Perindustrian dan Teknologi Informasi pada September 2026, disebutkan bahwa perlu mendorong transformasi perangkat lunak menuju kecerdasan, mengembangkan model seperti layanan agen cerdas, serta menekankanTidak melihat berapa banyak investasi, tetapi melihat seberapa efektif hasilnya. Bagi pihak pembeli, sinyalnya sangat jelas: jika masih hanya membandingkan hari kerja manusia dan jumlah personel yang berada di lokasi, mungkin Anda hanya akan mendapatkan “implementasi yang ramai”, tetapi tidak akan memperoleh perbaikan bisnis yang dapat diverifikasi.
Penilaian berdasarkan waktu vs penilaian berdasarkan hasil: apa perbedaannya?
| Dimensi | Penilaian tender tradisional berdasarkan orang/hari | Penilaian berbasis hasil |
|---|---|---|
| Indikator inti | Jumlah orang, tingkat, jumlah hari berada di lokasi, harga satuan | Lingkaran tertutup skenario, skrip penerimaan, KPI setelah peluncuran |
| Pengungkapan kebutuhan | Pilihan daftar fitur | Operasi posisi + standar data + aturan pengecualian |
| Penanganan perubahan | Negosiasi langsung untuk menambah personel dan anggaran | Dokumen perubahan memengaruhi milestone mana dan KPI mana |
| AI/agen cerdas | Biasanya tidak dimasukkan dalam penilaian | Meminta penjelasan mengenai titik peningkatan efisiensi, titik verifikasi manual, dan batas hak akses |
| Node pembayaran | Dibayar berdasarkan kuartal atau bulan kerja | Pembayaran dilakukan setelah penerimaan berdasarkan tonggak sejarah disetujui |
| Fokus sengketa | “Apakah orang-orang sudah siap?” | “Apakah skrip telah berjalan dengan lancar, apakah metrik telah membaik” |
Logika bisnis: Bagaimana cara mengubah dokumen tender?
Ubah dokumen pengadaan dari “membeli tenaga kerja” menjadi “membeli hasil”, disarankan untuk menulis ulang empat bagian:
- Daftar skenario: Tuliskan “keadaan saat ini dan masalah yang dihadapi → tindakan yang diinginkan” berdasarkan posisi, misalnya “Pembeli beralih dari pemesanan melalui email ke proses persetujuan PO dalam sistem secara tertutup”.
- Skrip penerimaan: Setiap skenario dilengkapi dengan langkah-langkah pengujian, data input, dan output yang diharapkan; pihak penawar wajib merespons ketercapaian setiap item secara terperinci.
- Janji KPI: Dalam 90 hari setelah peluncuran, indikator yang dapat diukur secara kuantitatif, seperti proporsi pemangkasan siklus persetujuan, tingkat perbedaan rekonsiliasi, dan tingkat akurasi persediaan—indikator tersebut harus dapat diambil datanya secara sistem.
- Batas layanan: Pelatihan, pemeliharaan operasional, migrasi data, serta pemeliharaan aturan agen cerdas masing-masing menjadi tanggung jawab pihak mana, guna menghindari situasi “selesai begitu diluncurkan”.
Saran bobot penilaian:Kesesuaian antara solusi dan hasil penerimaan 40% + efektivitas kasus serupa 30% + harga 20% + kemampuan tim 10%. Tim masih perlu dilihat, tetapi tidak boleh mendominasi, jika tidak maka akan kembali ke pola menambah jumlah orang.
Logika desain: Bagaimana agen cerdas dan otomatisasi masuk ke dalam penilaian tender
Jika solusi tersebut mencakup layanan pelanggan cerdas, pengingat otomatis, dan mesin aturan, pihak pembeli harus meminta pihak penawar untuk menjawab:
- Input dan output: Dokumen mana yang dibaca, status mana yang dikembalikan, apakah dapat diaudit.
- Izin dan Peningkatan: Operasi apa saja yang harus dikonfirmasi secara manual, dan bagaimana peningkatan jika terjadi timeout.
- Akurasi dan inspeksi acak: Bagaimana mengukur garis dasar komitmen, dan bagaimana melakukan rollback akibat kesalahan operasi.
- Penguncian pemasok: Apakah model, aturan, dan basis pengetahuan dapat diekspor, untuk menghindari kegagalan total saat beralih ke pabrik lain.
Pelaksanaan dan Penerimaan: Sistem Kontrol Akses Tahap III
Disarankan agar dalam kontrak secara jelas mencantumkan sistem kontrol akses tiga tahap, serta mengikat pembayaran dengan proses penerimaan:
- Tahap pertama (4–8 minggu): Skrip skenario inti telah lulus 100%, pelatihan bagi para pemangku kepentingan kunci telah selesai. Jika tidak lulus, pembayaran tahap kedua tidak akan dibayarkan.
- Tahap kedua (8–12 minggu): Proses lintas departemen telah terhubung, antarmuka dan data utama stabil, serta pengumpulan data dasar KPI telah diluncurkan.
- Tahap ketiga (90 hari operasional): Melakukan evaluasi ulang berdasarkan KPI kontrak; apabila tidak memenuhi standar, terdapat periode perbaikan dan ketentuan pemotongan dana, bukan penempatan staf di lokasi secara tak terbatas.
Jumlah personel di lokasi dapat dijadikan sebagaiLangkah pelaksanaanMenulis lampiran, tetapi seharusnya bukan merupakan objek kontrak utama. Objek kontrak utama seharusnya adalah “skrip mana yang telah lulus dan indikator mana yang telah ditingkatkan”.
Kesalahpahaman umum pihak pembeli
Kesalahpahaman pertama: memenangkan tender dengan harga per hari yang rendah——Perubahan pada tahap lanjut akan menaikkan harga, sehingga total biaya menjadi lebih tinggi. Solusi: batasi harga total + buat tabel penilaian perubahan.
Kesalahpahaman kedua: semakin banyak fitur, semakin baik——Tingkat peluncuran rendah. Solusi: lakukan secara bertahap berdasarkan skenario, dengan tahap pertama yang sedikit namun terintegrasi secara tertutup.
Kesalahpahaman ketiga: mengabaikan data master——Setelah sistem diluncurkan, data menjadi kacau dan tidak teratur, serta sistem cerdas memperbesar kesalahan. Solusi: Melakukan penerimaan terpisah untuk tonggak tata kelola data utama.
Kesalahpahaman keempat: tidak mendefinisikan standar pengambilan data KPI——Saat terjadi perdebatan, masing-masing pihak menghitung sendiri. Solusi: Rumus indikator, sumber data, dan periode statistik dimasukkan ke dalam lampiran, serta divalidasi oleh departemen informatika bahwa sistem dapat secara otomatis mengambil data.
Tindakan selanjutnya
Jika Anda sedang melakukan tender ulang untuk proyek CRM, ERP, SRM, atau proyek digitalisasi yang disesuaikan, Anda dapat terlebih dahulu melakukan “pemeriksaan kesehatan tender” selama satu minggu: tandai semua poin dalam RFP yang ada dengan warna merah, lalu ubah satu per satu menjadi skenario + skrip + KPI. Jika belum selesai mengubahnya, tidak apa-apa; setidaknya pada versi tender berikutnya, Anda tidak akan lagi memilih penyedia berdasarkan logika tahun 2015.
“Peningkatan teknis” dalam industri perangkat lunak tidak hanya terjadi di bengkel pihak kedua, tetapi juga di departemen pengadaan pihak pertama. Siapa pun yang lebih dulu menilai tender berdasarkan hasil, akan lebih mungkin memperoleh sistem manajemen yang benar-benar dapat digunakan, dapat dipertanggungjawabkan, dan dapat dilakukan evaluasi ulang di era kecerdasan buatan, bukan sekadar daftar panjang nama-nama orang.
Poin-poin tambahan yang perlu diperhatikan dalam pengadaan oleh perusahaan milik negara dan grup
Pengadaan berskala besar sering kali harus mempertimbangkan baik kepatuhan maupun efektivitas: dapat mempertahankan persyaratan kualifikasi dan ketentuan anti‑korupsi dalam dokumen tender, tetapiFormulir penilaian teknisHarus menetapkan “kelengkapan respons skrip penerimaan” dan “keterukuran KPI” sebagai komponen wajib, guna mencegah penilaian teknis hanya menjadi formalitas. Dalam skenario multi‑entitas grup, pihak penyedia tender sebaiknya diminta menjelaskan bagaimana data master dan hak akses mendukung anak perusahaan, serta memperluas implementasi setelah skrip berhasil diuji coba pada satu entitas dalam tahap pertama, bukan langsung menerapkan integrasi menyeluruh ke seluruh grup.
Pada sesi demonstrasi komite pengadaan, disarankan untuk secara langsung memilih 2–3 skrip yang akan dijalankan oleh pihak penawar, sementara para juri menilai berdasarkan output yang diharapkan—cara ini jauh lebih mendekati pengalaman nyata setelah sistem diterapkan dibandingkan hanya melihat presentasi PPT. Pada tahap negosiasi kontrak, masukkan “periode perbaikan dan formula pemotongan apabila KPI tidak tercapai” ke dalam isi utama kontrak; hal ini lebih mampu melindungi kedua belah pihak daripada mengandalkan negosiasi berbasis hubungan setelahnya. Reformasi penilaian tender tidak perlu menunggu hingga standar nasional versi berikutnya diterbitkan; pada proyek pengadaan berikutnya pun sudah dapat dilakukan uji coba dengan satu skrip, satu KPI, serta satu fase sistem akses. Melakukan uji coba secara bertahap dengan langkah kecil dan belajar dari kesalahan jauh lebih efektif untuk mengikuti perkembangan ganda—baik kebijakan maupun teknologi—daripada menunggu template yang sempurna.