Mengapa Proyek Otomasi Macet dan Cara Membuatnya Bergerak Kembali

Pilot berjalan dengan baik. Bot bekerja. Bot tersebut memproses faktur, atau merekonsiliasi data, atau menghasilkan laporan, dan melakukannya lebih cepat serta lebih akurat daripada proses manual yang digantikannya. Business case telah terbukti. Pimpinan terkesan. Lalu, entah bagaimana, tidak terjadi apa-apa selanjutnya. Proyek tidak gagal dengan cara yang dramatis. Proyek itu hanya berhenti berkembang. Bot pilot tetap berjalan, tetapi otomasi kedua dan ketiga tidak pernah terwujud. Program otomasi diam-diam macet.

Pola ini sangat umum. Data industri menunjukkan bahwa sekitar 50% proyek RPA gagal berskala melampaui tahap pilot, dan hanya sekitar 3% organisasi yang berhasil menskalakan RPA di seluruh enterprise. Kesenjangan antara pilot yang sukses dan program otomasi yang berskala adalah tempat sebagian besar inisiatif mati, dan alasannya lebih bersifat organisasional daripada teknis.

Alasan Paling Umum Proyek Macet

Pemilihan proses yang buruk untuk pilot. Ini adalah kesalahan paling fundamental, dan sering kali baru terlihat setelah pilot selesai. Jika pilot mengotomatisasi proses yang terlalu sederhana (tidak ada yang memperhatikan peningkatannya) atau terlalu kompleks (bot memerlukan pemeliharaan terus-menerus), hasilnya sama: organisasi kehilangan keyakinan terhadap nilai otomasi. Pilot yang menghemat waktu dua puluh menit per minggu untuk satu orang tidak menghasilkan momentum organisasi yang dibutuhkan untuk mendanai proyek kedua. Kerangka kerja pemilihan proses sangat penting karena pilot bukan sekadar bukti teknologi. Pilot adalah bukti nilai bisnis, dan jika nilai tidak terlihat, program akan macet.

Tidak ada struktur tata kelola. Pilot yang sukses sering terjadi karena satu tim antusias yang mendorong proyek maju. Penskalaan memerlukan sesuatu yang berbeda. Penskalaan memerlukan struktur tata kelola yang menentukan siapa yang mengidentifikasi kandidat otomasi, siapa yang menyetujui proyek, siapa yang membangun dan memelihara bot, siapa yang memantau kinerja, dan siapa yang memiliki roadmap otomasi. Tanpa struktur ini, setiap otomasi baru memerlukan upaya ad hoc yang sama dengan yang pertama. Tidak ada pipeline, tidak ada prioritisasi, tidak ada infrastruktur bersama. Setiap proyek dimulai dari nol, yang membuat biaya dan upaya setiap otomasi berikutnya terasa sama tingginya dengan yang pertama.

Ketidakselarasan TI dan bisnis. Banyak inisiatif otomasi dimulai di unit bisnis, didorong oleh orang-orang yang memahami kesulitan proses tetapi tidak memiliki keahlian teknis yang mendalam. Pilot mungkin dibangun oleh konsultan atau vendor. Penskalaan memerlukan keterlibatan TI untuk hosting, keamanan, akses jaringan, manajemen identitas, dan integrasi dengan sistem enterprise. Jika TI tidak terlibat sejak awal, transisi ini bisa menjadi kontroversial. TI mungkin memiliki kekhawatiran sah tentang keamanan, skalabilitas, dan pemeliharaan yang tidak dipertimbangkan oleh tim bisnis. Negosiasi yang dihasilkan dapat menghentikan program selama berbulan-bulan.

Ekspektasi yang tidak realistis. Vendor otomasi dan konsultan terkadang menjual berlebihan kemudahan dan kecepatan implementasi. Ketika pimpinan mengharapkan hasil yang cepat dan transformatif tetapi malah mendapatkan peningkatan inkremental dengan biaya pemeliharaan yang berkelanjutan, antusiasme memudar. Realitanya adalah bahwa otomasi memberikan pengembalian yang berakumulasi dari waktu ke waktu, tetapi tahap awal melibatkan upaya signifikan dalam analisis proses, pengembangan bot, pengujian, dan manajemen perubahan. Organisasi yang mengharapkan revolusi pada kuartal pertama akan kecewa, dan kekecewaan menyebabkan pemotongan pendanaan.

Meremehkan pemeliharaan. Bot yang berjalan bukanlah proyek yang selesai. Proses berubah, sistem diperbarui, aturan bisnis berkembang. Diperkirakan 70-75% dari total biaya RPA dialokasikan untuk implementasi, pemeliharaan, dan dukungan, dengan lisensi hanya mewakili 25-30% dari total biaya kepemilikan. Organisasi yang menganggarkan hanya untuk fase pembangunan menemukan diri mereka memiliki bot yang rusak ketika sistem yang mendasarinya berubah, dan tidak ada sumber daya yang dialokasikan untuk memperbaikinya. Bot yang rusak mengikis kepercayaan terhadap program otomasi lebih cepat daripada hampir apa pun yang lain.

Resistensi terhadap perubahan. Otomasi mengubah cara orang bekerja, dan tidak semua orang menyambut perubahan tersebut. Beberapa karyawan takut bahwa otomasi akan menghilangkan pekerjaan mereka. Yang lain merasa kesal bahwa proses yang telah mereka kelola selama bertahun-tahun diserahkan kepada mesin. Manajer mungkin menolak karena otomasi membuat kinerja proses transparan dengan cara yang mengekspos inefisiensi yang tidak ingin mereka soroti. Survei Deloitte menemukan bahwa 37% kegagalan RPA berasal dari praktik manajemen perubahan yang tidak memadai. Jika orang-orang yang berinteraksi dengan proses otomatis tidak mendukungnya, mereka akan menemukan cara untuk mengatasinya.

Cara Membuat Program yang Macet Bergerak Lagi

Bentuk Center of Excellence (CoE). CoE tidak perlu besar atau mahal. CoE dapat dimulai sebagai tim kecil, bahkan dua atau tiga orang, yang tugasnya memiliki siklus hidup otomasi: mengidentifikasi kandidat, memprioritaskan proyek, membangun atau mengawasi pembangunan bot, memantau kinerja, dan menangani pemeliharaan. CoE menyediakan kontinuitas dan pengetahuan institusional yang tidak dapat dilakukan oleh tim proyek ad hoc. CoE juga berfungsi sebagai titik kontak tunggal untuk unit bisnis yang ingin mengeksplorasi otomasi, yang mengurangi gesekan dalam memulai proyek baru.

Selaraskan TI dan bisnis sejak awal. Jika program Anda macet karena gesekan TI-bisnis, perbaikannya adalah dengan membawa TI ke dalam struktur tata kelola sebagai mitra, bukan penjaga gerbang. TI harus memberikan masukan tentang standar teknologi, persyaratan keamanan, dan keputusan infrastruktur. Bisnis harus memberikan masukan tentang pemilihan proses dan prioritas. Tidak ada pihak yang boleh dapat secara sepihak memblokir atau menyetujui proyek. Kepemilikan bersama menghasilkan keputusan yang lebih baik dan menghilangkan keterlambatan organisasi yang berasal dari hubungan yang bertentangan.

Setel ulang ekspektasi dengan metrik realistis. Jika program macet karena pimpinan mengharapkan lebih daripada yang diberikan, atasi hal ini secara langsung dengan data. Tunjukkan ROI aktual dari pilot, termasuk waktu dan biaya pemeliharaan. Proyeksikan ROI dari tiga hingga lima otomasi berikutnya berdasarkan estimasi yang realistis. Sajikan otomasi sebagai program yang memberikan nilai inkremental dan berakumulasi alih-alih transformasi sekali jalan. Ekspektasi yang berakar lebih mudah dilampaui, dan melampaui ekspektasi membangun kembali keyakinan.

Bangun pipeline, bukan hanya proyek. Program dengan satu bot adalah proyek. Program dengan backlog yang diprioritaskan dari dua puluh kandidat otomasi, yang dinilai berdasarkan upaya dan dampak, adalah strategi. Pipeline memberi pimpinan visibilitas ke roadmap masa depan dan memberikan jawaban yang jelas atas pertanyaan tentang ke mana investasi mengalir. Pipeline juga membuat alokasi sumber daya lebih mudah karena Anda dapat menunjukkan apa yang akan diberikan proyek berikutnya dan berapa biayanya, sebelum Anda membutuhkan anggaran.

Investasikan dalam manajemen perubahan. Berbicaralah dengan orang-orang yang pekerjaannya berubah. Jelaskan apa yang dilakukan dan tidak dilakukan oleh otomasi. Bersikaplah jujur tentang dampak terhadap peran. Dalam kebanyakan kasus, otomasi menghilangkan tugas, bukan pekerjaan, dan orang-orang yang memahami hal ini jauh lebih cenderung mendukung program tersebut. Identifikasi champion otomasi di setiap departemen yang dapat mengadvokasi teknologi dan membantu kolega mereka beradaptasi. Sisi manusia dari otomasi setidaknya sama pentingnya dengan sisi teknis, dan mengabaikannya adalah salah satu cara paling andal untuk menghentikan program.

Anggarkan untuk siklus hidup penuh. Jika program Anda macet karena kejutan pemeliharaan, sesuaikan model anggaran. Sertakan pemeliharaan, pemantauan, dan pembaruan berkala yang berkelanjutan dalam proyeksi biaya untuk setiap otomasi. Hal ini menghasilkan kalkulasi ROI yang lebih akurat dan menghilangkan situasi di mana bot rusak enam bulan setelah peluncuran dan tidak ada anggaran untuk memperbaikinya.

Bergerak Maju

Program otomasi yang macet bukanlah program otomasi yang gagal. Pilot membuktikan bahwa teknologinya bekerja. Tantangannya bersifat organisasional, bukan teknis, dan tantangan organisasional memiliki solusi organisasional. Pola paling umum di antara perusahaan yang berhasil menskalakan otomasi bukanlah bahwa mereka sepenuhnya menghindari kemacetan. Polanya adalah mereka mengenali kemacetan, mendiagnosis penyebabnya, dan membuat perubahan struktural yang spesifik untuk mengatasinya. CoE untuk menyediakan kontinuitas. Kerangka kerja tata kelola untuk memberikan arah. Pipeline untuk memberikan momentum. Metrik realistis untuk mempertahankan keyakinan. Manajemen perubahan untuk mempertahankan dukungan.

Perusahaan yang paling lama berjuang adalah mereka yang merespons kemacetan dengan meluncurkan pilot lain. Pilot kedua tidak menyelesaikan masalah yang menghentikan yang pertama. Pilot kedua hanya mengulanginya. Penskalaan otomasi memerlukan pembangunan infrastruktur organisasi untuk mendukungnya, dan itu adalah jenis pekerjaan yang berbeda dari membangun bot. Pekerjaan tersebut secara teknis kurang menarik tetapi pada akhirnya lebih penting.

Bacaan Terkait

• Membangun Kebiasaan Inteligensi Kompetitif yang Memakan 15 Menit Sehari
• Manfaat Kepatuhan dan Audit Trail dari Otomasi Proses
• Pemetaan Ketergantungan Mengungkap Seberapa Saling Terhubung Sebenarnya Proses Anda
• Uji Tuntas dalam 90 Menit, Bukan 90 Hari
• Otomasi Onboarding HR Dari Surat Penawaran hingga Hari Pertama