Manajemen ingin mempercepat approval dengan AI agent. Namun, belum jelas apakah permintaan tertahan karena pemeriksaan lama, dokumen kurang, atau transaksi baru dicatat setelah pekerjaan selesai. Process mining membantu menelusuri jejak proses pada sistem sebelum perusahaan memilih bagian yang perlu diotomasi.
Untuk process owner dan tim transformasi, tujuannya bukan membuat peta paling rumit. Tujuannya menemukan masalah yang bukti transaksinya dapat diperiksa, menguji penyebab bersama pelaksana, lalu memilih perubahan yang sesuai. AI dapat membantu analisis, tetapi tidak mengubah jejak sistem yang tidak lengkap menjadi gambaran operasi yang pasti benar.
Process Mining, Pemetaan Proses, Dan AI
Pemetaan proses melalui wawancara menjelaskan cara kerja yang diketahui atau diharapkan. Process mining menganalisis data kejadian dari sistem untuk melihat jalur transaksi yang tercatat. Dokumentasi UiPath menjelaskan pemanfaatan data sistem IT untuk menampilkan bottleneck dan penyimpangan melalui dashboard proses.
Kedua pendekatan saling melengkapi. Log menunjukkan urutan yang terekam, sedangkan wawancara membantu menjelaskan pekerjaan di luar sistem, alasan pengecualian, dan arti tiap status. Perbedaan antara SOP dengan log adalah bahan investigasi, bukan otomatis bukti pelanggaran.
Process mining juga tidak harus memakai generative AI. Model AI dapat membantu mengelompokkan alasan retur, merangkum variasi proses, atau menyusun hipotesis. AI agent dan orkestrasi lintas sistem baru relevan saat ada mekanisme tindakan. Menemukan antrean belum memberi izin menghapus approval atau menjalankan transaksi otomatis.
Tentukan Objek Yang Ditelusuri
Pilih satu proses dan satuan kasusnya. Untuk klaim layanan, satu kasus dapat berupa nomor tiket. Untuk pengadaan, pilih apakah analisis mengikuti permintaan pembelian, baris PO, atau invoice. Satu PO dapat memiliki banyak penerimaan dan invoice; menggabungkannya tanpa aturan dapat menggandakan kejadian dan menghasilkan jalur yang keliru.
Sepakati titik awal, akhir, pembatalan, dan kasus yang masih terbuka. Hindari menyebut proses selesai hanya karena status terakhir dalam ekstraksi adalah “disetujui”. Status itu mungkin belum mencakup penerimaan atau pembayaran. Hubungan objek perlu dipetakan bersama tim integrasi sistem bila jejak tersebar di ERP, CRM, dan aplikasi approval.
Event Log Minimum Yang Perlu Disiapkan
- Identitas kasus yang stabil dan dapat ditelusuri ke sumber.
- Nama aktivitas dengan definisi bisnis yang disepakati.
- Timestamp kejadian beserta zona waktu dan ketelitiannya.
- Identitas kejadian untuk menangani duplikasi.
- Sistem asal dan waktu ekstraksi untuk audit perubahan data.
- Atribut konteks yang relevan, seperti tipe kasus, nilai, cabang, atau kanal.
Jika tersedia, bedakan waktu mulai dan selesai aktivitas. Selisih antara dua kejadian tidak selalu berarti waktu kerja petugas. Jeda dapat berisi antrean, menunggu pelanggan, akhir pekan, atau pekerjaan yang tidak dicatat. Identitas pelaksana sebaiknya dibatasi atau dipseudonimkan sesuai tujuan analisis dan kebijakan organisasi.
Periksa timestamp mundur, kejadian dengan waktu sama, log hilang, dan data yang diimpor sekaligus. Bila sistem hanya menyimpan status terakhir tanpa riwayat perubahan, jelaskan bahwa rekonstruksi jalur historis terbatas. Jangan mengisi kejadian yang hilang seolah-olah benar-benar terjadi.
Membaca Antrean Tanpa Menuduh Tim Yang Salah
Skenario ilustratif: tiket dibuat Senin pukul 09.00, dokumen dinyatakan lengkap Selasa pukul 09.00, dan persetujuan diberikan Selasa pukul 11.00. Jeda sejak pembuatan sampai persetujuan adalah 26 jam kalender. Namun, 24 jam pertama terjadi sebelum dokumen lengkap. Menyebut seluruh 26 jam sebagai keterlambatan approver akan mengarahkan solusi ke masalah yang salah.
Analisis perlu membandingkan kelompok kasus yang setara. Kasus bernilai besar mungkin membutuhkan pemeriksaan tambahan yang memang diwajibkan. Bandingkan median dan persentil waktu, bukan rata-rata saja; periksa juga kasus terbuka agar transaksi paling lambat tidak hilang dari perhitungan.
Jalur yang berulang dapat menandakan rework, tetapi perlu validasi. Status “review” dua kali mungkin berasal dari koreksi dokumen, dua pemeriksa yang berbeda, atau pengiriman log ganda. Ambil beberapa kasus contoh dan telusuri kembali ke bukti sumber sebelum merancang perubahan proses.
Peran AI Yang Layak Diuji
AI dapat membantu mengelompokkan catatan bebas tentang dokumen kurang atau alasan penolakan. Buat kategori acuan dan minta pemilik proses memeriksa sampel hasilnya. Kategori “lainnya” serta kasus meragukan harus tetap tersedia; jangan memaksa setiap catatan masuk label yang terlihat rapi.
Untuk ringkasan bottleneck, minta keluaran menyertakan kelompok transaksi dan metrik pendukung. Bedakan temuan teramati dari dugaan penyebab. Korelasi cabang tertentu dengan waktu lama belum membuktikan cabang tersebut penyebabnya; perbedaan jenis kasus atau beban kerja dapat menjelaskan pola itu.
Jika model membantu menyusun kueri atau transformasi data, hasilnya perlu ditinjau dan diuji terhadap contoh yang diketahui. Versikan aturan transformasi. Rekomendasi yang berubah tanpa perubahan data perlu diperiksa, bukan langsung dijadikan dasar keputusan operasional.
Pilih Perubahan Berdasarkan Penyebab
Dokumen tidak lengkap mungkin memerlukan validasi formulir di awal. Duplikasi input dapat membutuhkan integrasi. Antrean approval dengan aturan tetap bisa cukup menggunakan workflow dan notifikasi. Kasus dengan informasi tidak terstruktur mungkin cocok untuk bantuan AI yang menyiapkan ringkasan sebelum review manusia.
Proses lintas sistem yang memerlukan AI agent tetap membutuhkan batas alat, identitas tindakan, persetujuan, serta penanganan gagal. Perubahan nilai transaksi, otorisasi pembayaran, dan pengecualian kebijakan memerlukan kewenangan yang telah ditetapkan. Jangan menjadikan rekomendasi analitik sebagai hak untuk melewati kontrol tersebut.
Untuk pengamatan aliran pada area produksi, value stream mapping dapat melengkapi log dengan pemeriksaan lapangan. Tidak semua waktu tunggu terlihat di aplikasi, sehingga pengukuran langsung tetap diperlukan untuk bagian proses yang belum tercatat.
Susun Pilot Dengan Bukti Sebelum Dan Sesudah
Validasi Data Dan Baseline
Pilih periode yang mewakili variasi operasi. Cocokkan jumlah kasus dengan laporan sumber, periksa beberapa transaksi dari awal sampai akhir, dan dokumentasikan bagian yang tidak teramati. Pemilik proses menyetujui definisi metrik sebelum tim membandingkan unit atau cabang.
Uji Satu Perubahan Terbatas
Ubah satu titik proses pada kelompok yang disepakati. Simpan waktu mulai, aturan baru, dan kelompok pembanding bila memungkinkan. Pantau waktu siklus, tingkat pengembalian, backlog terbuka, serta beban pemeriksa. Percepatan yang disertai kesalahan lebih banyak belum memenuhi tujuan pilot.
Putuskan Lanjut Dengan Konteks Biaya
Hitung waktu ekstraksi, pemetaan objek, pembersihan data, validasi bisnis, lisensi bila ada, dan pemeliharaan integrasi. Berkurangnya durasi kalender bukan otomatis penghematan jam kerja. Finance perlu memeriksa apakah hasil mengurangi lembur, menghindari biaya, atau menghasilkan kapasitas yang benar-benar digunakan.
Mulai Dari Satu Jejak Transaksi
Siapkan contoh kasus, sumber log, definisi status, PIC proses, serta keputusan yang ingin diperbaiki untuk diskusi pemetaan kebutuhan Layana.ID. Layanan konsultasi IT dan AI bisnis dapat dibahas sesuai hasil pemetaan, tanpa menganggap agentic AI sebagai jawaban untuk setiap antrean.
Referensi
UiPath: Introduction To Process Mining menjadi rujukan konsep analisis data proses. Contoh waktu, rancangan pilot, dan batas penggunaan AI merupakan analisis penerapan artikel ini.
Gambar merupakan ilustrasi AI, bukan dokumentasi proyek atau data transaksi pelanggan Layana.ID.