Kode pemasok sudah rapi, tetapi laporan belanja masih dipenuhi kategori “lain-lain”. Baut produksi, jasa kalibrasi, dan langganan aplikasi masuk ke kelompok yang sama karena deskripsi transaksi mengikuti kebiasaan masing-masing cabang. Procurement sulit melihat belanja yang layak digabungkan sebelum bernegosiasi.
AI klasifikasi belanja pengadaan dapat membantu mengusulkan kategori dari deskripsi transaksi. Hasilnya perlu diuji terhadap taksonomi perusahaan dan diperiksa manusia. Artikel ini membahas rancangan pilot untuk category manager, finance, dan pemilik master data; seluruh contoh merupakan ilustrasi, bukan hasil proyek Layana.ID.
Tentukan Keputusan yang Akan Memakai Hasil Klasifikasi
Mulailah dari pertanyaan yang spesifik: kategori mana yang perlu ditinjau kontraknya, pembelian mana yang tersebar lintas cabang, atau transaksi mana yang belum memiliki pemilik kategori. Jangan menjadikan persentase baris berhasil diberi label sebagai satu-satunya sasaran. Label yang lengkap tetapi keliru justru membuat perbandingan pemasok menyesatkan.
Batasi unit analisis pada baris transaksi, bukan nama vendor. Satu pemasok dapat menjual alat, suku cadang, dan layanan pemasangan. Menyalin kategori vendor ke semua baris membuat hasil terlihat konsisten sambil menghilangkan perbedaan kebutuhan. Procurement perlu menetapkan apakah klasifikasi mengikuti barang, tujuan pemakaian, atau akun biaya; ketiganya tidak selalu sama.
Bangun Taksonomi dan Contoh Pembatas
Siapkan daftar kategori beserta definisi, contoh masuk, contoh tidak masuk, dan penanggung jawabnya. Misalnya, “jasa pemeliharaan mesin” dibedakan dari “pembelian suku cadang mesin”, meskipun keduanya muncul pada satu invoice. Jika perusahaan memakai hierarki kategori, jelaskan kapan sistem boleh berhenti di tingkat induk.
Kategori “belum dapat ditentukan” harus tetap tersedia. Deskripsi “pembelian kebutuhan operasional” tidak cukup untuk menyimpulkan barangnya. AI sebaiknya meminta bukti tambahan, bukan menebak hanya agar semua transaksi mendapat label. Perbedaan interpretasi antarreviewer diselesaikan pada pedoman kategori terlebih dahulu, sebelum dianggap kesalahan model.
Pisahkan Rules, Model Klasifikasi, dan AI Agent
Mapping kode barang yang sudah disetujui cocok ditangani aturan deterministik. Model klasifikasi atau LLM berguna untuk deskripsi tidak seragam yang membutuhkan interpretasi bahasa. Workflow automation dapat mengurutkan proses impor, validasi, usulan, dan antrean review dengan jalur yang tetap.
AI agent baru relevan ketika sistem perlu memilih langkah pemeriksaan berikutnya, misalnya membaca referensi barang atau meminta bukti dari sumber yang diizinkan. Chatbot yang hanya menjawab pertanyaan tentang total belanja belum otomatis merupakan agent. Untuk pilot klasifikasi statis, jangan menambahkan kebebasan bertindak jika pemetaan berbasis aturan dan model sudah memadai.
Siapkan Data Tanpa Mengubah Catatan Keuangan
Gunakan salinan data dengan ID transaksi, ID baris, tanggal, entitas, deskripsi, kode barang, satuan, mata uang, nilai, dan kategori existing. Simpan juga versi taksonomi dan waktu pengambilan data. Hilangkan informasi pribadi atau rekening yang tidak diperlukan. Hak akses analisis tetap mengikuti entitas dan fungsi pengguna.
Nilai transaksi dan konversi mata uang harus mengikuti sumber keuangan yang disepakati. AI tidak boleh mengubah nominal atau membuat kurs untuk menutup data yang kosong. Pisahkan kolom kategori asli, usulan kategori, alasan, sumber pendukung, status review, dan keputusan final sehingga perubahan dapat ditelusuri.
Integrasi ke ERP dimulai melalui akses baca atau ekspor terkendali. Untuk kebutuhan koneksi antarsistem, bahas kontrak data melalui layanan sistem integrator Layana.ID. Menulis kategori hasil review ke laporan analitik berbeda risikonya dari mengganti akun pembukuan; jangan menyatukan kedua tindakan tersebut.
Contoh Alur Review pada Holding Multi-Cabang
Dalam skenario ilustratif, cabang mengirim tiga deskripsi: “servis kompresor”, “seal kompresor”, dan “paket servis berikut seal”. Sistem mencocokkan kode yang sudah dikenal terlebih dahulu. Deskripsi pertama masuk usulan jasa, kedua suku cadang, sementara baris paket diarahkan ke reviewer karena kemungkinan perlu pemisahan menurut kebijakan perusahaan.
Reviewer melihat teks asli, dokumen referensi yang boleh diakses, kategori kandidat, serta alasan singkat. Ia dapat menerima, mengganti, atau meminta rincian. Keputusan disimpan bersama identitas reviewer dan versi pedoman. Koreksi tidak langsung menjadi aturan global: pemilik kategori memeriksa apakah pola tersebut berlaku lintas cabang.
Uji Kualitas pada Sampel yang Mewakili Risiko
Susun dataset uji yang mencakup kategori dominan, kategori jarang, deskripsi singkat, bahasa campuran, transaksi bernilai besar, serta paket barang dan jasa. Pisahkan data untuk memperbaiki pedoman dari data uji akhir. Bila seluruh contoh uji sudah dipakai menyusun prompt, hasil evaluasi kurang mencerminkan transaksi baru.
- Ketepatan kategori: berapa usulan cocok dengan keputusan reviewer yang sudah direkonsiliasi.
- Cakupan per kategori: kategori mana yang sering tertukar atau terlalu sering ditolak.
- Kesalahan berbobot nilai: berapa nilai belanja terpengaruh salah kelompok, tanpa menyamakan itu dengan kerugian aktual.
- Beban review: waktu pemeriksaan, koreksi, dan permintaan dokumen per baris.
- Kelengkapan jejak: apakah setiap keputusan dapat dikembalikan ke sumber dan versi pedoman.
Jangan memperlakukan skor keyakinan yang ditulis model sebagai probabilitas benar yang terkalibrasi. Uji apakah kelompok usulan yang diprioritaskan memang lebih andal. Tetapkan batas penerimaan per kategori bersama pemilik keputusan, bukan mengambil angka generik dari demo vendor.
Jalankan Pilot dan Tetapkan Batas Otomasi
Awali dengan satu kelompok belanja dan beberapa cabang yang memiliki data cukup jelas. Jalankan klasifikasi paralel dengan proses existing, lalu bandingkan keputusan dan waktu kerja. Jika pedoman berubah di tengah uji, tandai versi baru dan ulangi pemeriksaan kasus yang terpengaruh. Jangan menggabungkan hasil dari definisi kategori yang berbeda menjadi satu skor.
Usulan berisiko rendah dapat diprioritaskan untuk review cepat, tetapi perubahan master kategori, akun biaya, atau strategi pemasok tetap memerlukan persetujuan pihak berwenang. Hentikan pemakaian hasil untuk negosiasi jika sumber tidak lengkap, kesalahan terkonsentrasi pada kategori penting, atau pekerjaan koreksi melebihi manfaat yang terukur.
Rujukan dan Langkah Berikutnya
Rancangan di atas merupakan rekomendasi implementasi, bukan jaminan hasil. NIST AI Risk Management Framework menjadi rujukan pengelolaan risiko AI. Baca juga perbandingan rules, OCR, dan LLM untuk memilih komponen pemrosesan dokumen.
Layana.ID menyediakan layanan AI dan machine learning untuk kebutuhan bisnis. Siapkan contoh transaksi yang sudah disamarkan, taksonomi kategori, tujuan analisis, batas akses, dan PIC review. Diskusikan pemetaan pilot klasifikasi belanja agar ruang lingkup dan bukti penerimaan ditentukan sebelum integrasi.