Hampir setiap perusahaan yang saya ajak kerja sama sebenarnya sudah punya banyak teknologi. Spreadsheet, grup chat, aplikasi project management, dashboard laporan, mungkin juga CRM yang tidak sepenuhnya dipercaya. Masalahnya jarang karena kekurangan tools. Masalahnya, tools itu tidak tersambung menjadi sistem yang benar-benar mendorong bisnis maju.
Itulah bedanya teknologi sebagai alat tambahan dan teknologi sebagai penggerak bisnis.
Mulai dari masalah, bukan dari produk
Cara paling umum proyek teknologi melenceng adalah ketika dimulai dari solusi: "kita butuh aplikasi", "kita harus pakai AI", "ayo pindah ke platform baru". Diskusinya langsung lompat ke fitur sebelum ada kesepakatan soal apa yang sebenarnya bermasalah.
Saya lebih suka memulai dengan tiga pertanyaan:
- Keputusan atau proses apa yang hari ini lambat, rawan salah, atau tidak terlihat?
- Siapa yang merasakan masalahnya — dan berapa biayanya dalam waktu, uang, atau peluang yang hilang?
- Seperti apa kondisi "lebih baik" yang benar-benar bisa kita amati?
Setelah ketiganya jelas, barulah masuk akal untuk membahas apa yang perlu dibangun.
Tes sederhana: menghilangkan pekerjaan, atau memindahkannya?
Tool baru yang mengharuskan orang menyalin data dari satu tempat ke tempat lain sebenarnya tidak menghilangkan pekerjaan — hanya memindahkannya. Salah satu sistem internal yang saya bangun untuk bisnis makanan omnichannel menggantikan lima spreadsheet terpisah dengan satu sumber data. Nilainya bukan pada dashboard-nya, tetapi karena tim berhenti berdebat soal angka mana yang benar dan berhenti menghabiskan hari-hari untuk copy-paste manual di akhir bulan.
Pola yang sama muncul di dashboard operasional IT: dulu request datang lewat WhatsApp dan brief lisan. Solusinya bukan sekadar "aplikasi ticketing" — tetapi membuat setiap request terlihat dan terprioritaskan, sehingga pekerjaan support dan development tidak lagi saling bertabrakan.

Data yang tersebar di kertas dan spreadsheet baru berguna setelah tersambung menjadi satu sistem. Foto: Jakub Żerdzicki / Unsplash.
Bangun untuk orang yang akan memakainya
Sistem yang benar secara teknis tetapi diabaikan penggunanya punya dampak nol. Karena itu saya memberi perhatian yang sama besar pada adopsi seperti pada arsitektur:
- Sesuaikan dengan alur kerja yang ada dulu, baru perbaiki. Meminta orang mengubah semuanya sekaligus adalah cara tercepat untuk membuat spreadsheet lama kembali dipakai.
- Berikan setiap role apa yang mereka butuhkan — tidak lebih. CEO, project manager, dan staf membutuhkan sudut pandang berbeda atas data yang sama.
- Buat kemenangan pertama terasa jelas. Kalau sistem baru menghemat satu jam seseorang di minggu pertamanya, adopsi akan berjalan dengan sendirinya.
Ukur apa yang berubah
"Sudah launching" bukanlah hasil. Sebelum membangun, saya suka menyepakati apa yang kita harapkan berubah — langkah manual yang berkurang, respons yang lebih cepat, keputusan yang diambil dari satu data bersama — lalu mengeceknya setelah launching. Tidak semua manfaat bisa diringkas jadi angka, tetapi kalau kita tidak bisa menjelaskan apa yang berubah, kemungkinan besar memang tidak banyak yang berubah.
Peran yang saya coba jalankan
Pekerjaan saya berada di antara bisnis dan teknologi. Di satu sisi, memahami operasional, prioritas, dan keterbatasan — tim kecil, data berantakan, budget terbatas. Di sisi lain, merancang dan membangun sistem, produk, dan otomasi yang tetap kokoh saat dipakai sungguhan.
Teknologi layak mendapat tempat ketika membuat bisnis lebih jelas, lebih cepat, atau lebih scalable. Selebihnya, ia hanya alat tambahan.
Punya proses yang terasa lebih berat dari seharusnya? Mari ngobrol.
