Menghubungkan AI Agents ke ERP, CRM, HRIS, dan Core Systems

Bayangkan tim finance Anda mulai menggunakan agent untuk membantu proses penutupan buku bulanan. Agent itu bisa membaca invoice, mencocokkan dengan purchase order, dan mendeteksi mana yang tidak cocok. Tapi begitu ia perlu tahu apakah goods receipt sudah diposting, apakah vendor masih aktif, atau apakah invoice itu sudah masuk workflow dispute, ia harus bertanya ke sistem yang menyimpan semua informasi itu. Di situlah masalah mulai terasa.

ERP, CRM, HRIS, atau sistem inti lain bukan sekadar database besar yang bisa diakses kapan saja. Mereka adalah tempat status bisnis resmi disimpan dan divalidasi. Order, invoice, data pelanggan, status karyawan, semua ada di sana. Agent tidak bisa bekerja dengan baik tanpa memahami state bisnis saat ini. Tapi banyak perusahaan menemukan bahwa sistem yang mereka miliki tidak dirancang untuk interaksi semacam ini.

Ini bukan soal model AI yang kurang canggih atau use case yang tidak menarik. Banyak program agentic AI melambat justru karena sistem inti sulit diakses, lambat, tidak konsisten, atau tidak aman untuk interaksi semi-otonom. CIO melihatnya sebagai masalah arsitektur. COO melihatnya sebagai masalah desain proses. CFO dan CHRO melihatnya sebagai masalah kontrol dan akuntabilitas.

Mengapa sistem inti sering menjadi hambatan

Sistem inti enterprise umumnya dibangun untuk standardisasi dan kontrol transaksi, bukan untuk interaksi dinamis seperti yang dibutuhkan agent. Beberapa hambatan yang umum muncul.

Akses real-time tidak selalu tersedia. Banyak sistem masih mengandalkan batch processing, replikasi data berkala, atau integrasi point-to-point yang lambat. Agent bisa mengambil keputusan berdasarkan data yang sudah tertinggal. Untuk use case analitis, ini mungkin masih bisa diterima. Tapi untuk use case operasional, ini berbahaya.

API mungkin sudah ada, tetapi belum tentu usable untuk workflow agentic. Cakupannya terbatas, dokumentasinya lemah, performanya tidak stabil, atau hanya cocok untuk aplikasi tradisional yang interaksinya sangat terstruktur. Agent perlu memanggil beberapa endpoint berurutan, membutuhkan validasi policy di tengah proses, atau harus berhenti dan melanjutkan kembali berdasarkan approval. Sistem inti belum tentu siap menghadapi pola seperti ini.

Kontrol akses sering terlalu kasar. Hak akses di sistem inti didesain untuk peran manusia, bukan untuk digital worker dengan scope sempit. Akibatnya, perusahaan terjebak: agent diberi akses terlalu luas, atau tidak bisa melakukan apa-apa.

Ada juga masalah semantik bisnis yang tersebar di luar sistem. Aturan bisnis nyata tidak hanya ada di ERP atau CRM. Sebagian hidup di spreadsheet tim, SOP lokal, email, knowledge base, atau kebiasaan operasional yang tidak terdokumentasi. Agent yang hanya terhubung ke sistem inti tanpa memahami lapisan aturan ini akan sering salah konteks.

Pola integrasi yang paling masuk akal: read, recommend, act

Kesalahan umum adalah ingin langsung membuat agent bisa melakukan transaksi. Pendekatan yang lebih sehat adalah bertahap. Pola read, recommend, act bukan sekadar roadmap teknis. Ia adalah cara mengelola risiko, membangun kepercayaan, dan mematangkan operating model.

Tahap 1: Read — agent memahami state bisnis tanpa mengubahnya

Pada tahap awal, agent sebaiknya fokus pada akses read-only ke sistem inti. Tujuannya memahami konteks transaksi, mendeteksi exception, merangkum status, dan memberi insight atau prioritas tindakan. Fase ini sering paling cepat menghasilkan nilai karena risikonya relatif lebih rendah.

Tim finance bisa menggunakan agent untuk membaca data ledger, status rekonsiliasi, dan histori exception guna menandai entitas atau akun yang berisiko terlambat close. Tim procurement bisa memanfaatkan agent untuk membaca intake request, vendor status, kontrak, dan histori pembelian, lalu mengarahkan requester ke jalur pembelian yang tepat. Customer operations bisa menyiapkan ringkasan kasus sebelum agen manusia menangani pelanggan. HR operations bisa memberi notifikasi proaktif tentang onboarding yang tertahan.

Nilai bisnis dari tahap ini datang dari pengurangan waktu pencarian data, prioritisasi exception, dan pengurangan handoff manual. Tapi read-only tidak cukup jika perusahaan ingin mengubah economics proses secara signifikan. Manusia tetap harus memindahkan keputusan ke sistem, membuat transaksi, mengirim follow-up, dan menutup loop.

Tahap 2: Recommend — agent menyiapkan tindakan, manusia menyetujui

Pada tahap ini, agent tidak hanya membaca. Ia mulai menyiapkan draft transaksi, membuat workflow request, menyusun rekomendasi tindakan, atau memicu langkah berikutnya yang masih membutuhkan approval manusia. Ini sering menjadi sweet spot untuk banyak fungsi enterprise.

Di accounts payable, agent bisa mendeteksi mismatch invoice, menyiapkan analisis akar masalah, lalu membuat draft case resolution untuk ditinjau petugas AP. Di sales operations, agent menyiapkan next-best action untuk account manager atau membuat draft update opportunity. Di HRIS, agent menyiapkan draft perubahan data karyawan, tetapi approval tetap dilakukan HR atau line manager. Di IT operations, agent mengumpulkan telemetry, menyarankan root cause, dan menyiapkan runbook action, tetapi engineer tetap menyetujui remediasi.

Manusia tetap memegang titik kontrol. Kualitas rekomendasi bisa dievaluasi. Organisasi belajar di mana agent benar-benar membantu versus di mana ia masih sering salah.

Tapi ada trade-off. Jika desain approval buruk, perusahaan hanya memindahkan bottleneck dari mencari data menjadi menyetujui draft agent. Approval harus dirancang dengan disiplin: hanya untuk tindakan yang memang perlu, dengan konteks yang cukup, dan dengan SLA yang jelas.

Tahap 3: Act — agent melakukan tindakan terbatas dalam batas yang jelas

Tahap paling matang adalah ketika agent dapat bertindak langsung di sistem inti. Kata kuncinya adalah terbatas. Bukan berarti agent bebas membuat transaksi apa saja. Yang lebih realistis adalah bounded autonomy: tindakan hanya untuk skenario tertentu, ada policy dan threshold, ada logging penuh, ada rollback atau compensating action, dan ada mekanisme penghentian jika perilaku menyimpang.

Customer service bisa memberikan agent wewenang memperbarui status tiket, mengirim komunikasi standar, atau memproses perubahan non-material pada order jika memenuhi policy. Collections bisa memberikan agent wewenang mengirim follow-up otomatis atau membuat promise-to-pay reminder. IT operations bisa memberikan agent wewenang menjalankan remediasi berisiko rendah seperti restart service tertentu. Procurement bisa memberikan agent wewenang membuat draft PO untuk kategori yang sangat standar.

Jangan memaksakan tahap act untuk domain yang menyentuh kontrol finansial material, berdampak hukum atau regulasi tinggi, memiliki data yang belum stabil, atau belum punya mekanisme rollback yang jelas. Posting jurnal material, perubahan vendor master sensitif, keputusan kompensasi karyawan, persetujuan kredit, atau perubahan policy pelanggan bernilai tinggi sebaiknya tetap mempertahankan human-in-the-loop untuk waktu yang lebih lama.

Agent tidak seharusnya menunggu ditanya

Banyak implementasi awal agent masih bersifat pasif: agent baru bekerja ketika seseorang bertanya atau menekan tombol. Ini berguna untuk copilot. Tapi untuk agentic operating model, pola yang lebih kuat adalah agent merespons perubahan bisnis saat perubahan itu terjadi.

Agent bekerja jauh lebih baik jika ia menerima sinyal seperti order changed, ticket escalated, invoice overdue, payment failed, inventory exception, employee onboarding delayed, atau shipment at risk. Dengan event seperti ini, agent tidak perlu terus-menerus polling sistem atau menunggu manusia menyadari masalah.

Polling manual atau query berkala membebani sistem inti, menciptakan latency, dan sering membuat agent bereaksi terlambat. Event-driven design memungkinkan agent bekerja lebih dekat ke ritme operasi nyata.

Di supply chain, ketika inventory turun di bawah threshold atau shipment tertunda, event dikirim ke bus. Agent control tower langsung menilai dampak ke order pelanggan, lalu menyiapkan opsi mitigasi. Di customer operations, ketika tiket naik ke prioritas tinggi, event memicu agent untuk menyusun ringkasan kasus dan rekomendasi eskalasi. Di finance, ketika invoice melewati due date, event memicu agent collections untuk memulai tindakan lanjutan.

Dua pola yang sering relevan adalah event bus, di mana sistem enterprise mempublikasikan event operasional ke platform bersama dan agent berlangganan event yang relevan, serta Change Data Capture (CDC), yang membantu menangkap perubahan pada data transaksi jika sistem inti belum punya event native yang baik.

Event-driven design juga memperbaiki observability. Setiap trigger, keputusan, dan action bisa ditelusuri sebagai rangkaian kejadian: event terjadi, agent dipicu, data tambahan diambil, policy dicek, tindakan dilakukan atau di-eskalasi. Bagi operasi, risk, dan audit, ini jauh lebih sehat daripada agent yang bekerja diam-diam di belakang layar.

Tentu ada trade-off. Event-driven architecture menambah kebutuhan standardisasi event, pengelolaan idempotency, penanganan event ganda atau terlambat, dan disiplin ownership lintas sistem. Jika fondasi integrasi perusahaan masih sangat lemah, mulailah dari domain yang event-nya paling jelas dan bernilai tinggi.

Jangan menunggu semua sistem sempurna

Salah satu alasan perusahaan lambat bergerak adalah asumsi bahwa semua core systems harus dimodernisasi dulu sebelum agent bisa dipakai. Ini tidak realistis. Pendekatan yang lebih tepat adalah modernisasi selektif berdasarkan capability yang paling dibutuhkan oleh use case prioritas.

Pertanyaan yang lebih berguna bukan "sistem mana yang harus diganti dulu?", tetapi "capability apa yang paling sering dibutuhkan oleh use case agentic prioritas?" Jika prioritas Anda adalah finance close, capability yang paling penting mungkin akses status close dan rekonsiliasi, pembacaan exception jurnal, pembuatan workflow issue, dan akses ke evidence repository. Jika prioritas Anda adalah customer operations, capability pentingnya mungkin baca histori pelanggan, baca dan update case, cek status order, dan kirim komunikasi standar.

Untuk sistem legacy yang sulit disentuh, pola yang paling efektif adalah membangun API facade atau service layer di depannya. Tujuannya menyederhanakan kompleksitas sistem lama, menormalkan schema, membatasi tindakan yang boleh dilakukan agent, dan menghindari ketergantungan pada UI atau direct database access. Agent seharusnya tidak bergantung pada klik layar, query langsung ke tabel inti, atau logika tersembunyi yang hanya dipahami segelintir orang. API facade juga membantu governance karena perusahaan bisa memutuskan bahwa agent hanya boleh berinteraksi melalui service yang sudah tervalidasi, diberi policy, dicatat, dan bisa dimatikan jika perlu.

Banyak program integrasi merasa selesai ketika endpoint sudah dibuat. Untuk agentic enterprise, itu belum cukup. Yang perlu diukur adalah apakah integrasi tersebut benar-benar layak untuk operasi. Waktu akses data untuk use case prioritas, reliability dan error rate API, kelengkapan event yang tersedia, jumlah workflow yang bisa dijalankan agent secara aman, dan frekuensi fallback ke manusia akibat kegagalan integrasi adalah metrik yang lebih relevan. Jika API ada tetapi sering timeout, schema berubah tanpa governance, atau event tidak konsisten, agent tidak akan dipercaya bisnis.

Implikasi untuk operating model dan governance

Menghubungkan agent ke core systems bukan proyek middleware semata. Begitu agent menyentuh ERP, CRM, atau HRIS, beberapa implikasi governance langsung muncul.

Setiap koneksi ke core system harus punya owner bisnis dan owner teknis. Tidak cukup "tim integrasi yang urus". Harus jelas siapa pemilik capability bisnis yang dibuka untuk agent.

Batas read, recommend, dan act harus formal. Jangan biarkan tiap tim menentukan sendiri tingkat otonomi tanpa kerangka bersama. Ini akan menghasilkan inkonsistensi kontrol.

Audit trail harus lintas sistem. Perusahaan harus bisa menjelaskan bukan hanya apa yang dilakukan agent, tetapi juga state bisnis apa yang dibaca dan perubahan apa yang dibuat di sistem inti.

Workforce impact harus dipikirkan sejak awal. Begitu agent bisa membaca dan bertindak di core systems, pekerjaan manusia akan bergeser. Tim operasi tidak lagi hanya memasukkan data atau mengejar status, tetapi lebih banyak menangani exception, approval, dan perbaikan policy.

Jangan biarkan integrasi agent tumbuh liar per fungsi. Jika setiap fungsi membangun koneksi sendiri ke ERP atau CRM tanpa standar bersama, perusahaan akan menciptakan technical debt baru dalam bentuk agent integration sprawl.

Pertanyaan reflektif

Bagi CIO, pertanyaannya adalah apakah digital core perusahaan benar-benar siap menjadi platform eksekusi agent, atau masih hanya menjadi sistem pencatatan yang sulit diakses secara aman.

Bagi COO, pertanyaannya adalah di proses mana bottleneck terbesar sebenarnya bukan pada orang, tetapi pada keterlambatan akses state bisnis dari sistem inti.

Bagi CHRO, jika agent mulai membaca dan memicu workflow di HRIS, peran mana yang akan bergeser dari administrasi ke oversight dan exception management.

Bagi transformation leader, apakah roadmap dimulai dari use case bernilai tinggi dengan capability integrasi yang realistis, atau masih terjebak antara demo AI yang menarik dan core systems yang belum siap disentuh.

Jika jawaban atas pertanyaan-pertanyaan ini masih kabur, prioritas berikutnya bukan menambah agent baru. Prioritasnya adalah memperjelas jalur aman antara agent dan sistem inti. Di situlah agentic enterprise benar-benar mulai menjadi nyata.