Saya sudah cukup sering duduk di rapat kickoff untuk bisa mengenali kegagalan sejak awal. Pemilik bisnis membuka proyek, menyampaikan beberapa kalimat soal betapa pentingnya inisiatif ini, lalu menyerahkan ruangan ke tim IT atau vendor eksternal dan pergi. Serah terima itulah, bukan softwarenya, bukan vendornya, bukan anggarannya, benang merah paling umum di balik alasan kegagalan transformasi digital yang saya temui sepanjang satu dekade menangani klien.

Pola pikir yang menyebabkan ini adalah memperlakukan transformasi seperti proses procurement: susun requirement, pilih vendor, tanda tangan kontrak, tunggu hasilnya, persis seperti memesan furnitur kantor. Cara ini berjalan baik-baik saja untuk software yang tidak mengubah cara orang bekerja. Transformasi itu berbeda secara definisi, tujuannya memang mengubah cara orang bekerja, dan perubahan semacam itu tidak akan bertahan kalau didelegasikan begitu saja dari orang yang benar-benar punya otoritas atas orang-orang tersebut.

Saya ingin menyampaikan, dari sudut pandang konsultan, bahwa ini sebenarnya masalah kepemilikan yang menyamar sebagai masalah teknologi, dan ada satu solusi spesifik yang, meski terdengar tidak nyaman, cukup efektif.

Kenapa Mendelegasikan ke IT Menjamin Kemacetan

Tim IT, baik internal maupun mitra pengembang outsourcing seperti yang saya jalankan, sangat mahir membangun apa pun yang diminta. Yang tidak bisa mereka lakukan adalah memaksa tim sales mengubah cara mereka mencatat kunjungan pelanggan, atau memaksa supervisor gudang untuk percaya pada sistem stok baru dibanding metode kertas yang sudah dipakai lima belas tahun. Otoritas itu ada di tangan pemilik bisnis atau pemimpin senior yang punya wibawa nyata atas orang-orang tersebut. Ketika transformasi didelegasikan hanya ke IT, softwarenya akan dibangun dengan benar lalu berakhir tidak terpakai, karena tidak ada orang yang punya otoritas untuk menegakkan adopsi yang benar-benar berdiri di belakangnya secara personal.

Saya pernah menyaksikan pola persis ini terjadi pada sebuah bisnis manufaktur keluarga yang menghabiskan anggaran cukup besar untuk sistem ERP, dibangun sesuai spesifikasi, dan delapan belas bulan kemudian ternyata separuh lantai produksi masih menyimpan catatan kertas paralel karena si pemilik sendiri tidak pernah memakai sistem itu dan tidak pernah bersikeras agar para supervisor lantai berhenti memakai cara lama. Softwarenya bukan penyebab kegagalan. Ketiadaan pemilik dalam prosesnyalah penyebabnya. Untuk gambaran lebih lengkap tentang bisnis yang melakukan transisi ini dengan benar, lihat Bisnis Manufaktur Keluarga yang Akhirnya Go Digital, di mana perbedaannya terletak pada keterlibatan langsung sang pemilik sejak minggu pertama.

Jebakan Delegasi, Disebutkan Secara Langsung

Beginilah bentuk persis jebakan ini: pemilik merasa transformasi itu "urusan teknis," sehingga harus jadi tanggung jawab siapa pun di perusahaan yang paling paham teknis. Ini terdengar seperti pembagian kerja yang masuk akal. Padahal ini sebenarnya pelepasan tanggung jawab, karena bagian tersulit dari transformasi bukan pernah soal membangun sistemnya secara teknis, melainkan membuat orang mengubah perilaku, dan hanya orang dengan otoritas organisasi yang bisa mendorong itu. IT bisa membangun alatnya. Hanya pemilik yang bisa membuat alat itu benar-benar berarti.

Tandanya kamu sudah jatuh ke jebakan ini: kalau kamu, sebagai pemilik, tidak bisa secara personal memandu seseorang menggunakan sistem baru di minggu pertama peluncurannya, berarti kamu sudah mendelegasikan terlalu banyak. Bukan karena kamu harus jago teknis, tapi karena kalau kamu sendiri tidak cukup paham untuk memakainya, kamu tidak bisa dengan kredibel mengatakan ke timmu bahwa ini tidak bisa ditawar.

Solusinya: Pemilik Memakai Sistem di Minggu Pertama

Langkah dengan dampak tertinggi yang selalu saya rekomendasikan justru terdengar sederhana: pemilik secara personal memakai sistem baru untuk menyelesaikan pekerjaannya sendiri yang nyata di minggu pertama rollout, secara terlihat, di depan tim yang akan memakainya. Bukan demo, bukan walkthrough dari vendor, melainkan pemilik yang mencatat transaksi sungguhan, menyetujui permintaan sungguhan, atau menarik laporan sungguhan dengan tangannya sendiri.

Ini melakukan tiga hal sekaligus:

  • Membuktikan sistemnya memang berfungsi untuk kasus nyata, bukan sekadar skenario demo yang sudah dikurasi vendor, sehingga bug sungguhan terlihat sebelum seluruh tim mengalaminya.
  • Memberi sinyal, tanpa perlu memo apa pun, bahwa ini bukan hal opsional atau proyek sampingan. Karyawan mengukur seberapa serius mereka harus berusaha dari apa yang secara nyata dianggap penting oleh pemimpinnya, bukan dari apa yang tertulis di email.
  • Memberi pemilik pemahaman langsung yang cukup untuk mengambil keputusan yang tepat saat tim melawan dengan alasan "cara lama lebih cepat," karena mereka sendiri sudah merasakan titik-titik friksinya dan bisa membedakan masalah yang genuine dari sekadar resistensi terhadap perubahan.

Bisnis keluarga khususnya cenderung meremehkan betapa pentingnya hal ini, karena kepemilikan dan manajemen begitu tumpang tindih sehingga semua orang sudah menganggap keterlibatan pemimpin sebagai hal yang otomatis. Tapi saya sudah melihat bisnis keluarga melewatkan langkah persis ini sesering perusahaan korporat, biasanya karena sang pendiri menyerahkan inisiatif ke anak "yang lebih jago komputer" lalu benar-benar lepas tangan. Lihat Suksesi Bisnis Keluarga Adalah Masalah Sistem untuk melihat bagaimana celah kepemilikan yang sama ini juga muncul dalam perencanaan suksesi, polanya sama persis.

Apa yang Sebenarnya Dibutuhkan dari Kepemilikan

Ini bukan berarti pemilik harus menulis kode atau mengelola proyek sehari-hari. Artinya ada tiga komitmen spesifik: secara personal memakai sistem baru untuk pekerjaan nyata di minggu pertama, secara personal mengomunikasikan bahwa proses lama akan dipensiunkan (bukan "berjalan paralel dulu untuk sementara," melainkan tanggal berakhir yang nyata), dan secara personal menangani percakapan penolakan pertama alih-alih mendelegasikan itu juga. Selain itu, pembangunan teknis, manajemen timeline, hubungan dengan vendor, semuanya bisa dan seharusnya didelegasikan. Tiga hal tadi tidak bisa.

Yang Perlu Dilakukan

Sebelum proyek transformasi berikutnya dimulai, tanyakan satu pertanyaan ke diri sendiri: apakah saya akan secara personal memakai sistem ini untuk pekerjaan nyata di minggu pertamanya? Kalau jawaban jujurnya tidak, kamu sudah menemukan penyebab kegagalan transformasi digital sebelum itu terjadi, dan kamu masih punya waktu untuk memperbaikinya. Perbaiki dulu celah kepemilikannya sebelum memperbaiki dokumen requirement. Softwarenya sangat jarang menjadi penyebab proyek-proyek ini macet. Ketiadaan seorang pemimpin yang mau jadi pengguna pertama, dan yang pertama bersikeras bahwa cara lama sudah berakhir, hampir selalu itulah penyebabnya.