Demo AI hampir selalu bagus.
Data sudah disiapkan.
Prompt sudah diuji.
Workflow lurus.
Tidak ada connector error.
Tidak ada user aneh.
Tidak ada spreadsheet dengan lima format tanggal.
Tidak ada email vendor yang attachment-nya rusak.
Lima belas menit presentasi terlihat seperti masa depan.
Masalah procurement dimulai setelah meeting selesai.
Software masuk ke environment nyata.
Data berantakan.
User berbeda-beda.
Policy banyak.
System legacy.
Dan semua edge case yang tidak pernah muncul di demo mulai datang.
Itu sebabnya procurement AI 2026 harus berubah.
Jangan membeli efek wow.
Beli capability yang bisa diukur.
Pertama, tentukan business problem sebelum lihat vendor.
Ini terdengar basic, tapi sering terbalik.
Perusahaan lihat teknologi dulu.
Lalu cari use case.
Akhirnya punya agent yang pintar tapi tidak menyelesaikan bottleneck penting.
Mulai dari process.
Misalnya procurement request butuh lima hari karena routing manual.
Customer service punya backlog.
Finance lama merekonsiliasi invoice.
HR kewalahan screening dokumen.
Tulis baseline.
Volume.
Cycle time.
Error rate.
Cost.
Escalation.
Satisfaction.
Baru cari AI.
Microsoft pada 2026 bahkan punya blueprint pengukuran agent value untuk procurement intake. KPI yang disarankan termasuk first-time-right routing, requisition cycle time, policy compliance, supplier cycle time, dan off-catalog spend.
Detail angkanya bisa berbeda tiap perusahaan.
Prinsipnya penting: ukur sebelum go-live.
Kalau baseline tidak ada, ROI hanya cerita.
Kedua, bedakan capability dan feature.
Feature adalah “bisa summarize invoice”.
Capability adalah “bisa memproses 10.000 invoice per bulan dengan error di bawah threshold, integrate ke ERP, log semua action, dan escalate exception”.
Procurement harus membeli capability.
Feature gampang didemokan.
Capability butuh bukti.
Minta vendor menunjukkan scale.
Minta reference architecture.
Minta SLA.
Minta observability.
Minta failure handling.
Minta evidence dari production use, kalau tersedia.
Ketiga, buat acceptance test.
Jangan cuma proof of concept dengan data terbaik.
Gunakan sample representatif.
Data bersih.
Data messy.
Bahasa Indonesia.
Singkatan internal.
File scan.
Format vendor beda.
Edge case.
Kalau use case customer-facing, masukkan variasi bahasa natural.
Kalau use case finance, masukkan exception.
Kalau use case procurement, test policy conflict.
AI harus lulus dunia nyata.
Bukan lab.
Keempat, definisikan quality metric.
Untuk routing, accuracy.
Untuk extraction, field-level accuracy.
Untuk summarization, completeness dan unsupported claim.
Untuk coding, test pass dan security scan.
Untuk customer service, resolution rate, escalation quality, dan complaint.
Jangan menggunakan “user merasa lebih cepat” sebagai satu-satunya metric.
Persepsi penting.
Tapi harus ada operational outcome.
Kelima, hitung cost per task.
Ini metric yang makin penting.
AI pricing bisa berbasis seat, token, compute, credit, action, atau kombinasi.
Satu agent mungkin murah per license tetapi mahal ketika volume naik.
Procurement harus membuat scenario.
Volume normal.
Peak.
Growth.
Model lebih kuat.
Context lebih besar.
Storage log.
Connector.
Support.
Hitung total.
Jangan baru kaget setelah invoice bulan ketiga.
Cost per task memungkinkan comparison lebih fair.
Misalnya workflow manual biaya RpX per request.
Agent menurunkan ke RpY termasuk human review.
Itu angka yang bisa dibawa ke CFO.
Keenam, ukur human review.
Banyak business case AI terlalu optimistis karena menganggap output otomatis.
Padahal user tetap harus cek 80 persen hasil.
Kalau AI menghemat 10 menit lalu review butuh 8 menit, value kecil.
Ukur actual touch time.
Berapa persen benar-benar hands-off?
Berapa persen hanya assisted?
Berapa persen gagal?
Ini menentukan ROI.
Ketujuh, jangan abaikan data preparation.
AI vendor sering bilang model bisa membaca data apa pun.
Reality tidak sesederhana itu.
Kalau nama vendor tidak konsisten.
SKU beda.
Dokumen scan buruk.
Policy tersebar.
Knowledge base stale.
Agent akan struggle.
Data cleanup punya biaya.
Masukkan ke procurement plan.
Jangan dianggap pekerjaan gratis tim internal.
Kedelapan, evaluasi security sebagai capability.
Bukan checklist.
Apakah identity granular?
Least privilege?
Audit log?
Encryption?
Data retention?
Private networking?
Key management?
Incident response?
Prompt injection defense?
Connector governance?
NIST pada 2026 menegaskan agent punya security challenge baru dan praktik cybersecurity perlu diadaptasi.
Security agent bukan cukup antivirus plus SSO.
Kesembilan, lihat governance lifecycle.
Siapa bisa membuat agent?
Siapa approve?
Siapa publish?
Siapa update?
Siapa retire?
Agent sprawl bisa cepat.
Microsoft guidance 2026 mendorong inventory, risk tier, release gate, role ownership, monitoring, dan lifecycle management.
Procurement sebaiknya menilai apakah platform membantu control ini.
Jangan hanya menilai builder UI.
Kesepuluh, lihat explainability sesuai risk.
Tidak semua AI perlu explanation detail.
Recommendation lagu tidak.
Credit decision jauh lebih penting.
Procurement harus menyesuaikan requirement.
Kalau agent membuat classification yang berdampak pada customer atau employee, perlu alasan yang bisa diaudit.
Kalau sistem hanya merangkum dokumen internal, requirement lebih ringan.
Risk-based.
Kesebelas, minta portability.
Data export.
Prompt export.
Workflow export.
Log export.
Connector mapping.
Kalau tidak bisa pindah, perusahaan harus tahu cost exit.
Vendor lock-in bukan otomatis buruk.
Tapi procurement yang tidak menghitung exit cost bekerja setengah.
Keduabelas, uji perubahan model.
Vendor AI bisa mengganti model.
Hasil bisa berubah.
Procurement perlu tahu notification policy.
Ada version pinning?
Ada regression test?
Bisa memilih model?
Apa yang terjadi jika model lama dihentikan?
Software AI lebih dynamic daripada SaaS tradisional.
Kontrak harus mencerminkan itu.
Ketigabelas, cek support untuk Indonesia.
Bahasa Indonesia.
Timezone.
Data residency jika relevan.
Support hours.
Local partner.
Invoice.
Tax.
Compliance.
Kalau agent dipakai tim operasi Jakarta pada jam kerja WIB, support yang hanya aktif waktu Amerika bisa menjadi problem.
Kualitas Bahasa Indonesia juga jangan dites dengan kalimat marketing saja.
Gunakan data internal nyata.
Bahasa campuran.
Singkatan.
Jaksel slang kalau memang customer service menghadapi itu.
Reality test.
Keempatbelas, nilai vendor maturity.
Seberapa lama produk production?
Ada roadmap?
Ada security documentation?
Ada incident history?
Ada enterprise customer?
Bagaimana response saat feature deprecated?
Startup baru bukan otomatis buruk.
Vendor besar bukan otomatis aman.
Yang dicari adalah operational maturity.
Kelima belas, kontrak harus punya service definition yang jelas.
Apa yang termasuk.
Apa yang dianggap usage.
Bagaimana overage.
SLA.
Data ownership.
Termination.
Breach notification.
Subprocessor.
Model changes.
Support.
Procurement AI tidak bisa hanya memakai template SaaS lama tanpa review.
Agent capability membutuhkan clause baru.
Ada juga satu jebakan umum: pilot gratis.
Gratis terdengar aman.
Tapi pilot yang tidak dirancang dengan success metric hanya menjadi demo panjang.
Sebelum pilot, tentukan exit criteria.
Kalau accuracy di bawah X, stop.
Kalau cycle time tidak turun, stop.
Kalau security gap tidak bisa ditutup, stop.
Kalau adoption rendah, investigate.
Pilot harus menghasilkan keputusan.
Bukan memperpanjang excitement.
Procurement juga perlu melibatkan user frontline.
Jangan cuma CIO dan vendor.
Orang yang melakukan proses setiap hari tahu edge case.
Mereka tahu supplier mana yang formatnya aneh.
Tahu langkah mana yang sebenarnya tidak perlu.
Tahu exception.
Kalau mereka tidak dilibatkan, agent mungkin automate diagram process, bukan process nyata.
Ada juga bias demo terhadap happy path.
Minta vendor menunjukkan fail.
Apa yang terjadi ketika confidence rendah?
Apakah sistem bilang tidak tahu?
Atau tetap membuat keputusan?
AI yang mature tahu kapan escalate.
Ini lebih penting daripada kemampuan menjawab semua.
Vendor yang jujur soal limitation biasanya lebih menarik daripada vendor yang bilang accuracy hampir sempurna tanpa konteks.
Procurement harus curiga terhadap angka tanpa methodology.
“90 persen lebih cepat.”
Dari apa?
Sample berapa?
Task apa?
Human review termasuk?
Environment production?
Data siapa?
Angka marketing bukan evidence.
Minta definisi.
Kalau tidak bisa, jangan masukkan ke business case.
Untuk perusahaan Indonesia, procurement juga perlu melihat kesiapan internal.
Apakah system punya API?
Apakah data boleh keluar?
Apakah approval process bisa berubah?
Apakah security team punya kapasitas?
Apakah user mau?
Tool terbaik tetap gagal kalau organisasi tidak siap.
Kadang keputusan procurement terbaik adalah memperbaiki process dulu.
AI belakangan.
Ada prinsip sederhana yang bisa dipakai CFO.
Setiap AI purchase harus menjawab:
Apa unit of work?
Berapa cost sekarang?
Berapa target cost setelah AI?
Apa quality threshold?
Apa risk control?
Berapa biaya implementasi?
Berapa waktu sampai value?
Kalau vendor tidak membantu menjawab ini, mereka menjual technology, bukan outcome.
Pada 2026, AI demo akan semakin susah dibedakan.
Semua bisa ngobrol.
Semua bisa buat slide.
Semua bisa summarize.
Differentiator enterprise bukan demo.
Differentiator adalah apakah capability tetap bekerja ketika data messy, user banyak, permission kompleks, dan error benar-benar punya consequence.
Procurement yang matang membeli reliability, governance, integration, dan measurable value.
Bukan animation di keynote.
Karena begitu kontrak ditandatangani, yang harus hidup dengan AI bukan sales engineer vendor.
Tim lo sendiri.
Ada satu aspek yang sering baru muncul setelah kontrak: adoption friction. Vendor bisa menunjukkan bahwa agent technically bekerja, tetapi user tetap memakai cara lama karena tidak percaya, interface terlalu ribet, atau workflow agent tidak sesuai kebiasaan. Procurement perlu memasukkan adoption metric sejak pilot.
Berapa persen user aktif?
Berapa task yang benar-benar pindah ke agent?
Berapa banyak user balik ke proses manual?
Kenapa?
Kalau adoption rendah, jangan otomatis salahkan user. Bisa jadi design-nya buruk.
Procurement juga perlu memisahkan productivity gain dan headcount assumption. AI bisa menghemat waktu, tetapi itu tidak otomatis berarti orang bisa dikurangi. Waktu yang kembali mungkin dipakai untuk quality, backlog, customer service, atau pekerjaan yang sebelumnya tidak sempat dilakukan.
Business case yang terlalu cepat memasukkan pengurangan headcount sering membuat resistance dan bias evaluasi.
Lebih sehat ukur capacity gain dulu.
Misalnya tim yang sama bisa memproses 30 persen lebih banyak request tanpa menambah orang.
Itu measurable.
Ada juga requirement training data atau grounding data. Vendor perlu menjelaskan apakah customer harus menyiapkan knowledge base, taxonomy, prompt library, atau policy mapping. Kalau iya, siapa yang maintain?
Knowledge base stale akan membuat agent stale.
Maintenance content adalah recurring cost.
Masukkan ke TCO.
Untuk model yang menggunakan retrieval, procurement juga perlu menanyakan citation dan source control. Apakah agent menunjukkan dokumen yang dipakai? Bisa membatasi sumber ke repository approved? Bisa memprioritaskan policy terbaru? Ini sangat penting untuk enterprise.
Kalau source lama dan baru bertentangan, system harus punya rule.
Jangan biarkan model memilih diam-diam.
Procurement juga perlu melihat observability setelah go-live. Dashboard usage saja tidak cukup. Perusahaan butuh error rate, escalation, latency, cost, tool failure, permission denial, dan quality trend.
Agent yang makin banyak tanpa observability akan menjadi black box operasional.
Dan terakhir, jangan terjebak bundling. Vendor besar bisa memasukkan AI ke kontrak existing dengan harga terlihat murah. Tetap lakukan evaluation. “Sudah termasuk license” tidak berarti implementation gratis atau capability-nya cocok.
Free tambahan tetap bisa mahal kalau process harus dibengkokkan agar cocok dengan tool.
Beli karena fit.
Bukan karena sudah ada di paket.
Bacaan terkait
Artikel ini berada dalam Industry Intelligence dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Reports dan analisis mendalam.