Jika Anda sedang duduk di depan transformasi digital yang gagal, software mahal yang tidak dipakai siapa-siapa, rollout yang diam-diam ditinggalkan tim Anda kembali ke spreadsheet, itu bukan kerugian total. Itu proyek penyelamatan dengan peluang sukses yang justru lebih besar dari proyek awal, karena sekarang Anda sudah tahu persis apa yang salah. Kesalahan yang biasa dilakukan pemilik bisnis di titik ini adalah menganggap solusinya adalah membeli software lain. Hampir tidak pernah begitu.
Saya sudah beberapa kali diminta masuk ke situasi seperti ini, yang paling baru untuk perusahaan multifinance yang sudah menggelontorkan budget besar untuk sebuah sistem yang stafnya di cabang berhenti membuka sistem itu setelah bulan kedua. Di setiap kasus, software itu sendiri hanya separuh dari masalahnya.
Diagnosis dulu sebelum menyentuh apa pun
Langkah pertama bukan rencana relaunch. Melainkan diagnosis jujur soal kenapa upaya pertama gagal, karena solusinya benar-benar berbeda tergantung jawabannya. Ada tiga kategori kegagalan, dan biasanya tidak ada yang mengumumkan dirinya dengan jelas.
Kegagalan alat. Software-nya memang benar-benar tidak bisa melakukan apa yang dibutuhkan bisnis: terlalu lambat, tidak punya alur kerja krusial, model data yang salah untuk cara bisnis itu sebenarnya beroperasi. Ini kegagalan yang paling jarang terjadi dari pengalaman saya, tapi justru yang paling dulu dituduh pemilik bisnis karena paling tidak menyakitkan untuk diakui.
Kegagalan proses. Software-nya sebenarnya baik-baik saja, tapi dibangun untuk mendigitalkan proses yang sudah rusak sejak awal, atau proses yang sebenarnya belum pernah disepakati siapa pun. Saya pernah melihat sistem yang mencoba menegakkan alur persetujuan yang ada di atas kertas tapi tidak pernah benar-benar diikuti siapa pun dalam praktiknya. Software itu hanya membuat disfungsinya menjadi terlihat dan kaku, alih-alih fleksibel dan berbasis kertas seperti sebelumnya.
Kegagalan adopsi. Alat dan prosesnya sama-sama baik-baik saja, tapi staf tidak pernah benar-benar mengubah perilaku mereka. Mereka merasa sistem baru lebih lambat dari kebiasaan lama, atau tidak ada yang menjelaskan kenapa perubahan ini penting bagi mereka secara personal, atau tidak ada konsekuensi ketika mereka kembali ke cara lama. Ini kegagalan yang paling sering terjadi, jauh di atas yang lain, dan justru yang paling jarang diakui pemilik bisnis karena menuding kepemimpinan dan manajemen perubahan, bukan vendor.
Ajak bicara orang-orang yang seharusnya memakai sistem itu setiap hari, bukan manajer yang menyetujui budgetnya. Tanyakan spesifik apa yang mereka lakukan sebagai gantinya, dan kenapa. Jawaban jujurnya hampir selalu sudah ada di sana, tinggal ditanyakan.
Selamatkan datanya sebelum memutuskan hal lain
Apa pun keputusan Anda soal software itu sendiri, data historis yang sempat diinput selama rollout yang gagal itu tetap punya nilai: data pelanggan, riwayat transaksi, apa pun yang sempat diinput staf sebelum mereka menyerah. Ekspor, bersihkan, dan simpan data itu, apa pun sistem yang akhirnya Anda jalankan ke depannya. Kehilangan riwayat itu karena penggantian sistem total adalah kerugian tambahan yang Anda ciptakan sendiri, di atas kegagalan yang sedang Anda pulihkan.
Ini juga saat yang tepat untuk memeriksa apakah kegagalan ini punya akar teknis yang layak dipahami tersendiri, terutama jika "sistem" yang dimaksud adalah aplikasi custom, bukan software siap pakai. Kadang keputusan yang tepat bukan relaunch, melainkan memutuskan apakah menulis ulang atau me-refactor apa yang sudah ada, alih-alih mulai dari nol.
Mulai ulang dari alur kerja paling sempit yang mungkin
Insting setelah rollout yang gagal adalah membuat upaya kedua lebih besar dan lebih menyeluruh, lebih banyak training, lebih banyak fitur, rencana rollout yang lebih lengkap. Ini justru terbalik. Upaya kedua harus lebih kecil dari yang pertama, bukan lebih besar.
Pilih satu alur kerja yang paling menyakitkan untuk dikerjakan manual hari ini dan paling mudah menunjukkan kemenangan cepat, lalu bangun atau konfigurasi ulang khusus untuk itu saja. Jangan relaunch seluruh sistem sekaligus. Kemenangan kecil yang cepat membangun kembali kepercayaan; rollout kedua yang komprehensif berisiko menjadi kegagalan komprehensif kedua, dan tim yang sudah dua kali gagal di inisiatif yang sama akan berhenti percaya bahwa akan ada upaya ketiga.
Ini disiplin yang sama dengan memetakan proses sebelum mengotomatisasinya: Anda tidak bisa memilih alur kerja sempit yang tepat untuk direlaunch kalau Anda belum memetakan secara detail di mana sebenarnya letak rasa sakit dan letak kegagalannya.
Tunjuk juara internal, bukan project manager
Setiap penyelamatan yang berhasil saya jalankan punya satu kesamaan: ada satu staf tertentu, bukan manajer, bukan konsultan eksternal, yang memakai sistem baru itu setiap hari dan dipercaya staf lain. Orang ini butuh tiga hal untuk berhasil: otoritas nyata untuk menuntut sistem itu benar-benar dipakai, dukungan yang terlihat dari manajer di atasnya, dan alasan yang meyakinkan bahwa alur kerja yang dipulihkan ini dipilih karena memang mengurangi beban kerja harian mereka.
Tanpa orang ini, Anda hanya mengandalkan mandat dari atas, yang justru adalah mekanisme yang gagal di percobaan pertama. Staf kembali ke spreadsheet karena tidak ada orang yang kredibel di lapangan yang benar-benar berkomitmen membuat sistem baru itu bertahan.
Jangan mulai dengan membeli lagi
Refleks setelah rollout gagal, apalagi kalau kegagalannya ditimpakan ke alatnya, adalah langsung mengevaluasi vendor baru. Tahan dulu sampai diagnosis di atas selesai. Kalau kegagalan sebenarnya ada di proses atau adopsi, yang biasanya memang begitu, vendor baru hanya memberi Anda rollout gagal kedua dengan invoice baru. Baru cari software baru setelah Anda memastikan, dari percakapan langsung dengan orang-orang yang meninggalkan sistem pertama, bahwa alatnya sendiri memang menjadi kendala sesungguhnya.
Urutan penyelamatan yang bisa Anda ikuti
- Wawancarai pengguna harian yang sebenarnya, bukan manajernya, soal apa yang mereka lakukan sebagai gantinya dan kenapa
- Kategorikan kegagalannya: alat, proses, atau adopsi
- Ekspor dan bersihkan data apa pun yang selamat dari rollout yang gagal
- Pilih satu alur kerja tersempit dan paling menyakitkan untuk direlaunch lebih dulu
- Tunjuk juara internal sungguhan dengan otoritas dan dukungan manajer
- Baru evaluasi software baru kalau diagnosis memang mengonfirmasi ada kesenjangan alat yang nyata
Kesimpulannya
Transformasi digital yang gagal adalah masalah diagnosis sebelum menjadi masalah teknologi. Sebagian besar rollout gagal di adopsi, bukan di software, dan pemulihan yang berhasil justru lebih sempit dan lebih lambat dari rollout ambisius yang pertama, ditopang satu juara internal yang dipercaya dan satu alur kerja yang cukup kecil untuk membuktikan kemenangannya dengan cepat. Kalau Anda sedang menatap sistem yang mandek dan tidak bisa memastikan sedang berada di kegagalan tipe yang mana, itu persis jenis penilaian yang layak mendapat sudut pandang kedua; Anda bisa menghubungi saya lewat halaman partner.