The Automation Trap: Kenapa yang Bisa Diautomasi Belum Tentu Harus Diautomasi

Hampir semua leader percaya satu hal yang sama soal automasi: semakin cepat diimplementasikan, semakin cepat pula hasilnya terasa. Keyakinan ini yang membuat investasi mengalir deras, survei McKinsey terhadap CFO lintas industri mencatat 65% organisasi berencana menambah investasi gen AI di tahun 2025, naik dari sekitar seperempat organisasi saja pada survei dua tahun sebelumnya.

Tapi keyakinan itu berbenturan dengan kenyataan di lapangan. Laporan McKinsey, “The State of AI in 2025: Agents, Innovation, and Transformation”, menemukan hanya 39% organisasi yang benar-benar melaporkan dampak ke EBIT di level enterprise, dan cuma sekitar 6% yang masuk kategori “AI high performer” dengan value signifikan dari investasi AI mereka, artinya sisanya belum merasakan hasil sebesar yang mereka harapkan. 

Paradoks inilah yang disebut automation trap, jebakan yang muncul begitu kecepatan implementasi dijadikan satu-satunya ukuran keberhasilan, tanpa memastikan proses bisnis yang diotomatisasi benar-benar sudah matang, aman, dan menciptakan value jangka panjang.

Artikel ini disusun dari wawancara tertulis dengan Michael Sitorus,Michael Sitorus, S.Kom., M.Kom., C.NA., C.HRA., C.Pro., C.PA dosen Program Studi Sistem Informasi di Universitas Siber Indonesia yang juga aktif meneliti perancangan sistem informasi untuk kebutuhan nyata. 

Automation Trap: Ketika Kecepatan Jadi Satu-satunya Ukuran Keberhasilan

Menurut Michael, automasi memang solutif. Ia membantu organisasi mencapai kecepatan kerja dan efektivitas proses berulang yang sulit ditandingi manusia. Tapi di balik daya tarik itu, ada risiko yang sering luput dari perhatian, terutama untuk pekerjaan yang berkaitan dengan aturan, kebijakan, atau keputusan yang sifatnya kondisional.

Semakin sebuah proses bergantung pada pertimbangan yang berubah-ubah, semakin besar potensi automasi tersebut justru menimbulkan masalah baru, bukan menyelesaikannya. Baginya, proses semacam ini sebaiknya dikecualikan dari automasi penuh, atau diarahkan ke sistem pendukung keputusan yang tetap melibatkan manusia.

Data lapangan mengkonfirmasi kekhawatiran itu. Laporan EY, “Get ready for robots”, mencatat 30–50% proyek RPA gagal di percobaan awal, angka yang sampai sekarang masih terus dikutip ulang karena pola kegagalannya tidak banyak berubah. 

Situs lowtouch.ai turut mengutip riset Gartner dan Forrester yang menyebut sekitar 30–50% proyek RPA enterprise ditinggalkan dalam dua tahun karena proses yang diotomatisasi ternyata terlalu kaku menghadapi perubahan nyata.

Persoalan yang sama terlihat pada gelombang automasi berikutnya. Gartner memperkirakan lebih dari 40% proyek agentic AI akan dibatalkan sebelum akhir 2027, dan alasannya bukan keterbatasan teknologi, melainkan biaya yang membengkak, nilai bisnis yang tidak jelas, dan kontrol risiko yang lemah. Riset dari California Management Review turut menegaskan, automasi yang hanya diarahkan untuk mengoptimalkan kecepatan tanpa batasan yang jelas cenderung mengorbankan value jangka panjang demi hasil instan jangka pendek.

Empat benchmark kegagalan proyek automation dan AI agentic di level enterprise.

Kerugian Tersembunyi yang Jarang Disadari Leader

Michael menyoroti satu pola yang menurutnya paling sering luput dari radar leader, yaitu efek berjenjang dari automasi yang diterapkan tanpa kesiapan. Ketika SOP belum benar-benar diuji coba tapi sudah langsung diimplementasikan ke sistem, organisasi tetap bergantung pada proses manual dan pada pemangku keputusan yang sama seperti sebelumnya. Bedanya, sekarang ada lapisan sistem baru yang harus ikut dipelihara.

Ia juga menekankan, dashboard yang menunjukkan proses berjalan lebih cepat bisa menyesatkan leader. Waktu proses yang memendek belum tentu diikuti kualitas keputusan, kepuasan pengguna, atau keamanan data yang ikut membaik. Bottleneck, menurut Michael, hanya berpindah tempat, dari pekerjaan manual ke pekerjaan mengelola sistem yang manualnya belum benar-benar selesai dirapikan.

Skala kerugian ini bukan isapan jempol. BCG mencatat 70% proyek digital transformation gagal mencapai target yang ditetapkan sejak awal. Analis independen Sandy Kemsley, dalam presentasinya “Maximizing Success in Automation Projects”, menghimpun data ini bersama estimasi bahwa kerugian dari proyek automasi yang gagal mencapai sekitar USD 260 miliar, hanya di Amerika Serikat. Riset lain yang dihimpun Level Up Coding mengutip Deloitte Consulting yang menyebut 37% kegagalan RPA berakar dari change management yang buruk, bukan dari kerusakan teknis bot itu sendiri. Sumber ini juga sekunder, artinya angka tersebut dikutip ulang dari laporan Deloitte, bukan ditautkan langsung ke laporan aslinya.

Pola ini tidak jauh berbeda dari yang terjadi pada automasi berbasis AI generatif. Kesenjangan antara kecepatan pengiriman output dan kesiapan tim untuk memvalidasinya kerap menjadi bottleneck baru, sama seperti yang dialami tim engineering yang buru-buru vibe coding tanpa proses review yang memadai.

Risiko Low-Code No-Code Ketika Masuk ke Skala Enterprise

Low-code no-code awalnya dipilih karena mampu mempercepat pengembangan aplikasi dan memungkinkan deployment tanpa bergantung penuh pada developer. 

Tapi Michael mengingatkan, di level enterprise, kemudahan ini butuh governance yang kuat. Tanpa itu, hak akses bisa berpindah tangan tanpa disadari penggunanya, dan berpotensi menimbulkan kebocoran data karena standar pengembangan atau workflow yang tidak sesuai aturan.

Ia juga menyebut masalah klasik yang muncul belakangan, yaitu kesulitan migrasi dan integrasi, karena aplikasi yang dibangun citizen developer sejak awal tidak mengikuti arsitektur yang konsisten.

Kekhawatiran ini tercermin jelas dalam data industri. Survei keamanan Forrester tahun 2026 mencatat 61% IT leader menjadikan risiko shadow IT dari citizen development yang tidak diawasi sebagai kekhawatiran utama mereka. 

Konsekuensinya nyata secara finansial. Laporan IBM Cost of a Data Breach 2025 menempatkan shadow IT sebagai salah satu dari tiga faktor teratas yang mendorong naiknya biaya kebocoran data. Ini sejalan dengan yang disampaikan Michael, 

“low-code no-code hanyalah alat. Kalau proses bisnis di baliknya belum matang dan tidak diawasi, alat secanggih apa pun hanya mempercepat munculnya risiko, bukan menghilangkannya.”

Michael Sitorus, S.Kom., M.Kom., C.NA., C.HRA., C.Pro., C.PA

Dosen Program Studi Sistem Informasi di Universitas Siber Indonesia

Cara Menentukan Apakah Proses Bisnis Aman untuk Diautomasi

Bagi Michael, keberhasilan automasi tidak ditentukan oleh teknologi yang dipakai, melainkan oleh kematangan proses bisnisnya. AI, workflow automation, atau low-code no-code, semuanya hanya alat, kalau proses bisnisnya sendiri belum stabil.

Ia menawarkan lima pertanyaan sederhana yang perlu dijawab sebelum organisasi memutuskan mengotomatisasi sebuah proses:

1. Apakah prosesnya sudah stabil dan terdokumentasi dengan baik?
2. Apakah aturan bisnisnya jelas dan konsisten?
3. Apakah keputusan yang diambil bersifat rutin, atau justru butuh pertimbangan manusia?
4. Apa dampaknya kalau sistem salah mengambil keputusan?
5. Apakah ada mekanisme audit, monitoring, dan evaluasi yang berjalan?

Michael punya rekam jejak menerapkan prinsip ini dalam salah satu risetnya sendiri berjudul Digitalisasi Administrasi Rumah Sakit: Transformasi Sistem Informasi dalam Meningkatkan Efisiensi Pelayanan Kesehatan.

Dalam kajian tersebut, Ia yang menyoroti bahwa Sistem Informasi Manajemen Rumah Sakit hanya efektif kalau kesiapan infrastruktur dan sumber daya manusianya sudah dipetakan lebih dulu, bukan sekadar mengejar efisiensi di atas kertas.

Dengan kata lain, pertanyaan yang perlu diajukan bukan “teknologi apa yang harus kita pakai”, melainkan “apakah proses ini sudah cukup matang untuk dipercayakan ke sistem”.

Kapan Manusia Harus Tetap Terlibat dalam Automasi

Karena automasi tetap membawa risiko, Michael menyarankan porsi keterlibatan manusia yang jelas, idealnya sekitar 50% dari keseluruhan proses, khususnya pada bagian yang sifatnya mengambil keputusan dari kebijakan atau SOP yang berlaku. 

“AI berperan mengolah data dalam jumlah besar dan berulang, lalu memberi rekomendasi. Tapi keputusan akhir untuk kasus kompleks, seperti persetujuan transaksi bernilai besar, aspek legalitas dan kepatuhan, atau evaluasi rekrutmen, tetap ada di tangan manusia sebagai decision maker”

Michael Sitorus, S.Kom., M.Kom., C.NA., C.HRA., C.Pro., C.PA

Dosen Program Studi Sistem Informasi di Universitas Siber Indonesia

Prinsip human-in-the-loop ini juga tercermin dalam riset Michael tentang aplikasi DONORIN, platform koordinasi donor darah yang dirancang menggunakan pendekatan Human Centered Design. Aplikasi ini mengotomatisasi notifikasi dan pencatatan digital untuk mempercepat koordinasi antara permintaan darah dan ketersediaan pendonor. 

Tapi keputusan yang menyangkut kesehatan, seperti verifikasi kelayakan donor, tetap memerlukan penilaian pihak rumah sakit dan Unit Transfusi Darah, bukan sepenuhnya diserahkan ke sistem.

Pola ini konsisten dengan yang berlaku di luar konteks riset Michael. Ketika keputusan berdampak besar atau berisiko tinggi, keterlibatan manusia bukan bentuk resistensi terhadap teknologi, melainkan mekanisme quality control yang justru mengurangi kemungkinan kesalahan fatal.

Prinsip Membangun Automasi yang Benar-Benar Menciptakan Value Jangka Panjang

Menutup wawancara, Michael menekankan pentingnya mengubah cara berpikir organisasi, dari “bagaimana kita mengotomatisasi proses ini” menjadi “bagaimana kita mendesain proses bisnis yang benar lebih dulu”. 

Automasi seharusnya menjadi langkah setelah proses bisnis diperbaiki, bukan pengganti perbaikan itu sendiri.

Ia menyarankan organisasi membangun AI Policy yang jelas, semacam aturan main tentang apa yang boleh dan tidak boleh dikerjakan AI, sehingga batasan antara yang diotomatisasi dan yang tetap ditangani manusia menjadi eksplisit sejak awal. Setiap workflow, menurutnya, juga harus dirancang dengan prinsip keamanan sejak awal, terutama saat menyentuh data enterprise, dan terus dimonitor bukan hanya di tahap peluncuran, melainkan berkelanjutan, mencakup akurasi data, performa, akses, hingga kepatuhan terhadap regulasi yang berlaku.

Mekari Officeless sebagai Solusi Governance untuk Automation Workflow Enterprise

Kebutuhan akan lapisan governance semacam ini yang mendorong hadirnya Mekari Officeless. Berperan sebagai control plane, Mekari Officeless menetapkan siapa boleh membangun apa, data apa yang boleh diakses, dan guardrail apa yang wajib dilalui sebelum sebuah workflow atau aplikasi hasil automasi maupun low-code no-code dipublikasikan, melalui kombinasi policy-as-code, approval workflow, dan auditability by default.

Mekari Officeless hadir sebagai extended ERP yang menutup gap operasional bisnis lewat solution accelerators, mulai dari ready-made apps, custom workflow dan dashboard, hingga layanan pengembangan kustom, yang semuanya dibangun di atas standar governance dan keamanan sejak awal.

Didukung No-Code AI app builder, Mekari Officeless memungkinkan organisasi membangun custom workflow yang cepat diimplementasikan, enterprise-grade security, dan efisien secara biaya, tanpa mengorbankan kontrol yang justru paling sering hilang dalam automation trap.

Platform ini dibangun secure by design mengikuti standar seperti ISO 27001 sejak fondasi, menyediakan komponen dan konfigurasi yang sudah tervalidasi untuk mengurangi duplikasi logika bisnis, serta menjaga arsitektur tetap konsisten lewat integrasi berbasis OpenAPI untuk menekan risiko shadow IT.

Organisasi bisa mulai dari kapabilitas yang sudah tersedia, lalu menambah kompleksitas secara bertahap sesuai kematangan operasionalnya, sehingga kecepatan automasi tidak pernah mengorbankan akuntabilitas.