Permintaan pengadaan yang belum lengkap membuat procurement mengulang pekerjaan. Pengguna meminta barang, gudang memiliki kode berbeda, dan engineering mengirim spesifikasi melalui lampiran terpisah. Sebelum vendor dapat memberi penawaran yang bisa dibandingkan, PIC harus menyatukan kuantitas, satuan, persyaratan teknis, serta lokasi pengiriman. AI agent persiapan RFQ dapat membantu menelusuri kekurangan ini dan menyusun draf untuk pemeriksaan.
RFQ atau request for quotation adalah permintaan penawaran berdasarkan kebutuhan yang cukup jelas. Pilot yang dibahas di sini berhenti pada draf RFQ siap review. Pengiriman ke vendor, perubahan spesifikasi, pemilihan pemasok, serta penerbitan purchase order tetap mengikuti wewenang perusahaan. Contoh berikut merupakan skenario ilustratif, bukan studi kasus pelanggan Layana.
Masalah yang perlu diselesaikan sebelum agent dibangun
Bayangkan pabrik memerlukan spare part untuk beberapa mesin. Purchase requisition berisi nama singkat dan jumlah, sementara foto serta drawing berada di folder lain. Procurement belum mengetahui apakah permintaan mengacu pada barang yang sama dengan master ERP. Jika agent langsung menyusun email penawaran, kesalahan identitas barang hanya akan berpindah ke vendor dengan bahasa yang lebih rapi.
Procurement manager perlu menentukan definisi RFQ lengkap bersama engineering dan pengguna. Tentukan field wajib per kategori: kode material, deskripsi, kuantitas, satuan, versi drawing, parameter wajib, lokasi, batas waktu, serta ketentuan substitusi. Bedakan spesifikasi yang sudah disahkan dari catatan yang masih perlu dikonfirmasi. AI tidak berwenang mengisi kekosongan dengan angka yang tampak masuk akal.
Kapan workflow cukup, kapan perlu AI agent?
Jika seluruh field sudah tersedia dan urutannya tetap, workflow deterministik dapat mengisi template RFQ. Model AI dapat dipakai untuk mengekstraksi lampiran atau membantu merapikan deskripsi. Chatbot hanyalah kanal interaksi dan tidak menentukan arsitektur di belakangnya.
Agent menjadi relevan ketika langkah pencarian bergantung pada konteks: memeriksa master material, mencari drawing aktif, melihat referensi pemakaian, lalu memilih pertanyaan klarifikasi. Kebutuhan dinamika itu harus terbukti dari kasus nyata. Jangan memberi label agentic hanya karena ada ringkasan AI atau beberapa API dalam satu workflow. Semakin banyak kebebasan memilih tool, semakin jelas batas data dan penghentian yang dibutuhkan.
Susun kontrak data sebelum kontrak tool
Sumber identitas barang dan versi spesifikasi
ERP menjadi sumber referensi kode material sesuai tata kelola perusahaan. Document management menyimpan drawing yang disahkan, bukan semua lampiran sebagai versi setara. Setiap draf mencatat ID requisition, baris item, versi sumber, timestamp pemeriksaan, dan bagian informasi yang masih kosong. Jika dua kode tampak mirip, agent mengusulkan pemeriksaan kepada engineering, bukan menyatukannya sendiri.
Untuk persoalan kode ganda dan ownership, gunakan fondasi master data management ERP. Artikel RFQ ini fokus pada kesiapan paket permintaan penawaran, bukan merancang ulang seluruh master material.
Field komersial dengan pemilik yang jelas
Deadline penawaran, lokasi penyerahan, dan format respons berasal dari template yang disahkan procurement. Persyaratan garansi atau instalasi tidak boleh disalin dari transaksi lama tanpa pemeriksaan. Harga historis dapat menjadi referensi internal yang dibatasi aksesnya; jangan otomatis memasukkannya ke dokumen vendor. Batas anggaran dan daftar pemasok yang diundang merupakan keputusan yang terpisah dari ekstraksi spesifikasi.
Alur agent dari requisition menuju paket review
- Baca requisition berizin. Tool memeriksa identitas pengguna, unit pemilik, dan status permintaan. Requisition yang dibatalkan atau belum disetujui tidak diproses seolah-olah sudah siap ditawarkan.
- Periksa kelengkapan per kategori. Validator yang konsisten menentukan field wajib; model membantu memahami lampiran dan menjelaskan kekurangan.
- Ambil sumber pendukung. Agent hanya mencari dokumen dalam cakupan izin item dan pengguna. Tautan ke sumber disertakan dalam paket internal reviewer.
- Ajukan klarifikasi terarah. Jika toleransi dimensi atau kebutuhan substitusi tidak tersedia, pertanyaan menyebutkan field yang hilang dan PIC teknis yang perlu menjawab.
- Susun draf RFQ. Draf membedakan informasi terkonfirmasi, usulan redaksi, dan data yang belum lengkap. Satu item tidak boleh diam-diam hilang ketika lampiran gagal dibaca.
- Tahan untuk approval. Procurement memeriksa aspek komersial, engineering memeriksa spesifikasi, dan pemilik permintaan mengonfirmasi kebutuhan. Setelah disahkan, kanal pengiriman menggunakan proses perusahaan.
Approval harus mengunci isi yang benar-benar dikirim
Persetujuan draf versi pertama tidak berlaku otomatis untuk draf yang berubah. Simpan nomor versi atau hash dokumen yang disetujui. Jika kuantitas, drawing, atau penerima berubah, minta review ulang sesuai kebijakan. Cegah sistem mengambil spesifikasi baru setelah approval tetapi sebelum pengiriman tanpa menampilkan perubahan kepada reviewer.
Tool untuk membuat draf tidak perlu memiliki izin mengirim email. Pisahkan read, draft, approve, dan send sebagai tindakan berbeda. Untuk pilot awal, send tetap berada di luar agent. Koneksi yang diperlukan dapat dipetakan melalui layanan sistem integrator Layana, dengan rincian izin dan kontrak data ditentukan pada discovery.
Risiko operasional yang perlu diuji
PDF hasil scan dapat membuat satuan atau tanda desimal salah terbaca. Jangan memakai hasil ekstraksi sebagai spesifikasi sah tanpa pemeriksaan field kritis. Buat validator tipe, satuan, serta batas nilai sesuai kategori. Drawing yang memiliki revisi baru harus menandai draf lama sebagai perlu review. Lampiran vendor atau email bebas merupakan data tidak tepercaya; kalimat di dalamnya tidak boleh memperluas izin agent.
Gangguan ERP harus menghasilkan status tertunda, bukan requisition kosong. Gunakan ID pekerjaan untuk mencegah draf ganda ketika proses diulang. Jika pembuatan draf sudah berhasil tetapi respons konektor hilang, periksa hasil pada ID yang sama sebelum mencoba kembali. Catat kegagalan parsial per item agar reviewer dapat melihat mana yang belum diperiksa.
Pilot satu kategori dengan ukuran keberhasilan yang jelas
Pilih kategori yang memiliki pemilik spesifikasi dan riwayat requisition cukup terstruktur. Hindari memulai dari seluruh pengadaan strategis. Procurement menjadi owner proses; engineering bertanggung jawab atas label spesifikasi; IT menyiapkan akun tool terbatas dan observability. Gunakan salinan data yang telah disanitasi ketika menguji perilaku yang dapat menyebabkan kesalahan.
- Field kritis benar: bandingkan kuantitas, satuan, versi, dan parameter teknis terhadap sumber yang disahkan.
- Kekurangan terdeteksi: hitung field wajib yang benar-benar hilang dan berhasil ditandai, serta field lengkap yang keliru dianggap kosong.
- Draf siap review: ukur draf yang dapat diperiksa tanpa petugas mencari ulang semua sumber.
- Waktu penyelesaian: sertakan durasi klarifikasi dan review, bukan hanya durasi model menghasilkan teks.
- Kontrol transaksi: periksa draf ganda, pengiriman tanpa approval, dan perubahan isi setelah approval; setiap kejadian harus ditelusuri.
Masukkan kasus satuan berbeda, barang serupa, drawing kedaluwarsa, kebutuhan mendadak, serta ERP tidak merespons. Uji kesalahan yang dapat mahal bagi procurement, bukan hanya pertanyaan mudah. Target KPI merupakan keputusan pilot yang harus disepakati; artikel ini tidak menyatakan persentase akurasi atau penghematan yang sudah dicapai.
FAQ AI agent untuk RFQ
Apakah agent boleh memilih vendor termurah?
Pilot persiapan RFQ tidak mencakup pemilihan vendor. Perbandingan vendor membutuhkan kriteria kualitas, kesesuaian, risiko, dan proses approval tersendiri. Harga terendah saja tidak menunjukkan penawaran paling sesuai.
Apakah semua lampiran harus dibaca AI?
Tidak. Tentukan lampiran yang diperlukan, jenis dokumen yang didukung, batas ukuran, dan pengecualian data. Dokumen yang gagal dibaca tetap ditandai untuk pemeriksaan manusia.
Brief implementasi untuk procurement
Siapkan contoh requisition anonim, template RFQ aktif, kategori pilot, daftar field wajib, sumber drawing, serta matriks approval. Jelaskan apakah hasilnya draf internal atau dokumen yang akan dikirim melalui proses terpisah. Pemetaan AI bisnis Layana dapat menjadi awal diskusi integrasi. Diskusikan kebutuhan pilot agent RFQ dengan tim Layana untuk menetapkan cakupan, dependensi, dan keluaran yang dapat diterima.
Referensi
Rujukan primer: Anthropic, Building Effective Agents, mengenai pemilihan arsitektur dan tool; NIST, AI Risk Management Framework, untuk identifikasi dan pengelolaan risiko AI. Ditinjau 13 Oktober 2026. Kontrak field, approval, serta KPI pengadaan merupakan analisis rancangan dalam artikel ini, bukan spesifikasi produk atau bukti proyek pelanggan.