Cara Mengidentifikasi Proses Otomatisasi Berdasarkan ROI dan Risiko

Daftar ide automation biasanya mudah dibuat. Finance ingin mempercepat invoice, HR ingin mengotomatisasi onboarding, sales ingin mengurangi input CRM, sementara operations ingin mempercepat approval.

Tantangannya adalah menentukan mana yang harus dikerjakan lebih dulu.

Cara Mengidentifikasi Proses yang paling bernilai membutuhkan lebih dari sekadar mencari pekerjaan repetitif. Organisasi perlu membandingkan benefit, effort, risiko, kesiapan teknologi, dan dampaknya terhadap KPI.

Dengan framework sederhana, automation roadmap bisa disusun berdasarkan nilai bisnis, bukan sekadar permintaan departemen atau tren teknologi terbaru.

Jangan Mulai dari Teknologi

Pertanyaan pertama seharusnya bukan:

“Proses mana yang bisa menggunakan AI atau RPA?”

Mulailah dengan:

“Masalah operasional mana yang paling mahal atau paling menghambat?”

IBM menekankan bahwa process mining membantu organisasi memahami proses berdasarkan data aktual, mencari akar masalah, kemudian menentukan perubahan atau automation yang memberikan dampak terbesar.

Misalnya perusahaan memiliki customer complaint tinggi karena order membutuhkan empat hari untuk diproses.

Jangan langsung membuat bot.

Cari tahu dahulu penyebabnya.

Bisa jadi masalah terbesar adalah approval yang menunggu dua hari, data customer tidak lengkap, atau order harus dimasukkan ulang ke tiga sistem.

Setelah bottleneck ditemukan, baru tentukan apakah solusinya automation, process redesign, integration, atau perubahan policy.

Pendekatan ini menghindari automassi hanya demi terlihat modern.

Hitung Nilai Ekonomi dari Pekerjaan Manual

Automation membutuhkan investasi, sehingga kandidat harus memiliki nilai ekonomi yang cukup.

Gunakan rumus sederhana:

Annual Manual Hours = Volume Tahunan × Waktu per Transaksi

Misalnya finance memproses 24.000 invoice per tahun dengan waktu rata-rata delapan menit.

Total manual effort adalah 192.000 menit atau sekitar 3.200 jam.

Jika automation mampu menghilangkan 70% pekerjaan tersebut, potensi penghematannya mencapai sekitar 2.240 jam setahun.

UiPath menggunakan faktor seperti frequency, activity volume, processing time, employee cost, error, rework, serta review time untuk mengukur kondisi proses sebelum automation.

Namun jangan langsung menganggap seluruh waktu yang dihemat menjadi cash saving.

Sering kali manfaat sebenarnya berbentuk kapasitas tambahan. Tim dapat menangani volume lebih besar tanpa menambah karyawan atau mengalihkan waktu ke pekerjaan bernilai tinggi.

Masukkan Error Reduction ke Business Case

ROI tidak selalu berasal dari waktu.

Beberapa proses menghasilkan kerugian besar akibat kesalahan kecil.

Misalnya salah memasukkan satu digit rekening vendor dapat menyebabkan pembayaran gagal. Kesalahan harga pada order bisa memicu credit note dan keluhan customer.

Hitung:

Jumlah error × biaya rata-rata per error.

Biaya ini bisa mencakup rework, refund, penalty, overtime, dan customer support.

UiPath menilai average error rate dan rework time sebagai bagian dari automation assessment karena dua faktor tersebut dapat meningkatkan workload secara signifikan.

Proses dengan error rate hanya 2% mungkin terlihat baik.

Tetapi jika terdapat 100.000 transaksi per tahun, berarti sekitar 2.000 transaksi bermasalah.

Pada volume besar, error kecil berubah menjadi peluang automation yang besar.

Bandingkan Business Value dengan Implementation Effort

Setelah benefit diketahui, ukur kompleksitas teknisnya.

Buat matriks dua sumbu:

Business Value dan Implementation Effort.

Kandidat dengan value tinggi dan effort rendah menjadi quick wins.

Value tinggi dan effort tinggi masuk strategic automation.

Value rendah tetapi effort rendah bisa dikerjakan jika ada kapasitas.

Value rendah dan effort tinggi biasanya ditunda.

Kesiapan teknis bisa dinilai dari jumlah aplikasi, ketersediaan API, struktur data, stabilitas aplikasi, jumlah process variant, dan kebutuhan judgement manusia.

UiPath bahkan memasukkan application changes expected, jumlah aplikasi, jumlah variasi proses, data structure, serta digital input ke assessment kandidat automation.

Contohnya, automated report generation dari database modern mungkin jauh lebih mudah daripada mengambil informasi dari enam aplikasi legacy.

Walaupun benefit kedua proses sama, implementation effort-nya sangat berbeda.

Gunakan Process Mining ketika Volume Data Sudah Besar

Interview dengan karyawan berguna, tetapi manusia tidak selalu mengingat detail proses dengan akurat.

Orang cenderung menjelaskan bagaimana pekerjaan seharusnya dilakukan, bukan seluruh variasi yang benar-benar terjadi.

Process mining menggunakan data event dari sistem untuk merekonstruksi alur aktual.

Microsoft menjelaskan bahwa process mining dapat memperlihatkan langkah nyata proses, menemukan error dan noncompliance, membandingkan proses, serta menemukan peluang automation.

SAP Signavio juga menggunakan process intelligence untuk menemukan inefficiency, bottleneck, dan area improvement berdasarkan operasi aktual serta benchmark.

Misalnya SOP purchase-to-pay menunjukkan lima tahap.

Process mining ternyata menemukan 18 variasi.

Sebanyak 30% invoice kembali ke tahap sebelumnya akibat missing purchase order.

Insight ini menunjukkan bahwa automation invoice entry saja tidak cukup. Validation di awal mungkin memberikan dampak lebih besar.

Cari Aktivitas yang Membuat Process Cycle Time Membengkak

Proses tidak selalu lambat karena task-nya lama.

Sering kali yang terbesar justru waiting time.

Misalnya satu approval hanya membutuhkan tiga menit untuk membaca, tetapi rata-rata menunggu 20 jam sebelum disentuh.

Di sinilah automation seperti routing, reminder, auto-approval berbasis threshold, atau delegation bisa membantu.

ServiceNow memberikan contoh penggunaan process mining untuk mencari routine approval, routing, request for information, dan data entry sebagai kandidat automation ketika aktivitas tersebut memakan waktu manusia tetapi relatif sedikit membutuhkan judgement.

Ukur dua hal secara terpisah:

Processing Time – waktu saat seseorang benar-benar mengerjakan.

Waiting Time – waktu pekerjaan hanya menunggu.

Jika waiting time mendominasi, solusi terbaik belum tentu RPA.

Workflow automation atau policy redesign mungkin lebih efektif.

Ini sebabnya melihat proses end-to-end lebih penting daripada hanya mengotomatisasi satu layar.

Hindari Proses yang Akan Segera Berubah

Automation sangat bergantung pada stabilitas proses.

Bayangkan tim menghabiskan dua bulan membuat bot untuk sistem procurement lama. Tiga bulan kemudian perusahaan mengganti ERP.

Investasi tersebut kemungkinan tidak optimal.

UiPath memasukkan perubahan proses dan perubahan aplikasi yang diperkirakan dalam enam bulan ke depan sebagai bagian dari detailed assessment automation.

Tanyakan:

Apakah aplikasi akan diganti?

Apakah kebijakan sedang direvisi?

Apakah struktur organisasi akan berubah?

Apakah proses tersebut sedang masuk proyek transformasi lain?

Jika ya, automation bisa ditunda atau didesain menggunakan pendekatan yang lebih tahan terhadap perubahan.

Stabilitas bukan berarti proses tidak boleh pernah berubah. Tetapi semakin sering rule dan UI berubah, semakin tinggi biaya pemeliharaan automation.

Nilai Risiko dan Compliance

Proses berisiko tinggi memerlukan pendekatan berbeda.

Automation pada payroll, payment, access management, atau regulatory reporting membutuhkan kontrol lebih kuat dibanding otomatisasi laporan internal sederhana.

Evaluasi dampak jika automation melakukan kesalahan.

Apakah hanya menunda pekerjaan 10 menit? Atau bisa mengirim pembayaran salah senilai ratusan juta rupiah?

Gunakan human-in-the-loop untuk keputusan berisiko.

Automation dapat mengumpulkan data, melakukan validasi awal, dan memberikan rekomendasi. Keputusan akhir tetap dilakukan orang dengan kewenangan yang sesuai.

Pastikan juga ada audit trail, exception handling, dan rollback.

Proses dengan business value tinggi tetapi risiko besar tetap layak diotomatisasi, namun tidak selalu menjadi kandidat pertama bagi organisasi yang baru memulai automation.

Buat Automation Priority Score

Agar penilaian konsisten, buat skor 100 poin.

Sebagai contoh:

Business impact: 25 poin.
Manual effort: 20 poin.
Transaction volume: 15 poin.
Error reduction: 10 poin.
Rule stability: 10 poin.
Data readiness: 10 poin.
Technical simplicity: 10 poin.

Proses dengan skor 80 ke atas dapat menjadi prioritas tinggi.

Namun gunakan skor sebagai alat bantu, bukan keputusan otomatis.

Ada faktor strategis yang sulit dimasukkan angka, seperti customer experience, compliance, atau kebutuhan mendukung ekspansi bisnis.

Microsoft Power Automate sendiri menggunakan process mining dan automation recommendation untuk membantu mengidentifikasi aktivitas yang bisa diotomatisasi dari process map.

Pendekatan yang baik adalah menggabungkan data kuantitatif dengan judgement process owner.

Dengan cara itu, roadmap automation tidak hanya berdasarrkan feeling.

Validasi dengan Pilot sebelum Scale

Setelah proses dipilih, jangan langsung mengotomatisasi 100% volumenya.

Jalankan pilot.

Misalnya mulai dari satu business unit, satu tipe invoice, atau satu wilayah.

Bandingkan outcome dengan baseline.

Ukur processing time, exception rate, error rate, hours saved, dan user experience.

Kalau pilot tidak menghasilkan improvement yang diharapkan, cari penyebabnya sebelum memperluas deployment.

Process mining juga dapat digunakan kembali setelah perubahan untuk memonitor KPI dan melihat apakah proses baru benar-benar lebih baik.

Microsoft dan SAP sama-sama menempatkan monitoring dan continuous improvement sebagai bagian dari pendekatan process intelligence.

Pilot membantu mencegah organisasi memperbesar automation yang ternyata hanya memindahkan bottleneck ke bagian lain.

Cara Mengidentifikasi Proses yang layak diotomatisasi lebih dulu membutuhkan keseimbangan antara ROI, error reduction, cycle time, technical effort, risiko, dan kesiapan data.

Gunakan process mining jika proses sudah kompleks, lalu validasi kandidat melalui pilot. Buat automation scorecard sekarang agar investasi diarahkan pada proses yang menghasilkan outcome terbesar, bukan sekadar paling mudah dibuat.