Setiap pemilik bisnis yang saya ajak bicara ingin tahu software apa yang harus dibeli. Hampir tidak ada yang bertanya hal yang sebenarnya menentukan apakah software itu akan berhasil: apakah proses di baliknya sudah benar? Membenahi proses bisnis sebelum software adalah urutan yang tidak glamor, tapi justru itulah yang membedakan rollout yang balik modal dalam tiga bulan dari yang diam-diam ditinggalkan pada bulan keenam.

Berikut pola yang terus-menerus saya lihat. Sebuah jaringan retail di Tangerang membeli sistem inventory karena stock opname mereka berantakan. Tiga bulan kemudian, stock opname masih berantakan, hanya saja sekarang di dalam interface yang lebih mahal. Tidak ada yang membenahi masalah sesungguhnya, yaitu tiga staff berbeda mencatat barang masuk dengan tiga cara berbeda, dan tidak ada yang benar-benar bertanggung jawab atas langkah rekonsiliasinya.

Software tidak memperbaiki proses yang rusak. Software mengotomatisasi apa pun proses yang Anda masukkan, lebih cepat dan dalam skala lebih besar. Masukkan kekacauan, dan Anda mendapatkan kekacauan yang disampaikan dengan lebih percaya diri, karena sekarang kekacauan itu keluar dari sistem yang terlihat otoritatif.

Kenapa "digitalisasi dulu" berbalik jadi bumerang

Naluri untuk membeli software terlebih dulu terasa produktif. Anda sedang melakukan sesuatu. Dashboard, aplikasi, sistem baru, semuanya adalah tanda kemajuan yang terlihat dan bisa Anda tunjukkan ke board atau partner. Membenahi SOP terasa tidak terlihat, hanya sebuah dokumen yang tidak akan dibaca siapa pun.

Tapi otomatisasi adalah pengganda, bukan pembenah. Jika proses persetujuan diskon Anda bergantung pada mood manajer mana pun yang sedang bertugas hari itu, mengotomatisasinya hanya berarti software sekarang menyetujui diskon yang tidak konsisten dengan lebih cepat dan disertai audit trail yang rapi yang membuktikan hal itu terjadi. Anda tidak menghilangkan inkonsistensinya. Anda mendokumentasikannya.

Kerusakannya menumpuk lewat tiga jalur khusus:

  1. Biaya lisensi yang terbuang. Anda membayar bulanan untuk tool yang tidak dipercaya siapa pun karena tool itu mencerminkan proses input yang sudah rusak.
  2. Kekesalan staff. Tim menyalahkan "sistem barunya" padahal biang keroknya adalah proses yang diminta untuk dikodekan sistem tersebut.
  3. Rollout kedua yang gagal. Begitu staff menyimpulkan bahwa proyek software selalu gagal di sini, rollout berikutnya dimulai dengan resistensi aktif, bukan lagi skeptisisme netral.

Saya pernah menyaksikan sebuah perusahaan multifinance mengalami persis ini dengan sebuah tool collections. Toolnya sendiri baik-baik saja. Proses eskalasi yang sedang didigitalisasi tidak pernah didokumentasikan, sehingga setiap collector menafsirkan "follow up" dengan cara berbeda-beda. Solusinya bukan sistem baru, melainkan dua minggu kerja proses sebelum menyentuh software itu lagi. Kasus terkait di digitalisasi collections multifinance ini membahas penyelamatan serupa secara lebih rinci.

Urutan yang benar

Dokumentasikan, sederhanakan, baru otomatisasi. Dalam urutan itu, setiap saat.

  • Dokumentasikan proses sebagaimana benar-benar berjalan hari ini, bukan sebagaimana yang tertulis di struktur organisasi. Turun langsung ke lapangan. Bicara dengan orang yang benar-benar mengerjakan tugas itu, bukan deskripsi dari manajernya.
  • Sederhanakan sebelum mendigitalisasi. Hilangkan langkah persetujuan yang ada hanya karena kebiasaan. Gabungkan entri data yang duplikat. Hapus langkah apa pun yang satu-satunya alasan keberadaannya adalah "memang begini dari dulu."
  • Otomatisasi versi yang sudah disederhanakan. Sekarang software sedang mengkodekan sesuatu yang memang layak dikodekan, dan staff bisa melihat bahwa software membuat pekerjaan mereka lebih mudah, bukan sekadar berbeda.

Langsung lompat ke langkah tiga adalah alasan paling umum kenapa rollout software ditinggalkan. Ini juga sebabnya technical debt menumpuk dengan cepat, karena sistem yang dibangun di atas proses yang tidak terdokumentasi butuh patching terus-menerus begitu realita dan software mulai berbeda arah, pola yang saya bahas lebih dalam di Technical Debt Dijelaskan untuk Pemilik Bisnis.

Latihan pemetaan SOP 90 menit yang bisa Anda jalankan minggu ini

Anda tidak perlu konsultan untuk memulai. Sisihkan 90 menit bersama dua atau tiga orang yang benar-benar menyentuh proses itu setiap hari, bukan sekadar manajernya, lalu jalankan ini:

Langkah Waktu Yang perlu dicatat
1. Tulis setiap langkah secara berurutan 20 menit Tulis setiap tindakan nyata di sticky note atau baris item, jangan diedit dulu
2. Tandai titik keputusan 15 menit Di mana manusia harus memilih antar opsi? Siapa yang memutuskan, dan berdasarkan apa?
3. Tandai pengecualian 15 menit Apa yang terjadi ketika ada yang salah, stok habis, atau terlambat?
4. Lingkari langkah yang redundan atau sekadar kebiasaan 15 menit Tanyakan "apa yang rusak kalau ini dihilangkan?" untuk tiap langkah
5. Gambar ulang versi yang sudah disederhanakan 20 menit Satu alur bersih, idealnya di bawah 10 langkah untuk kebanyakan proses UMKM
6. Tetapkan pemilik proses 5 menit Satu nama per langkah. Jangan kepemilikan bersama, di situlah akuntabilitas mati

Lakukan ini sebelum Anda meminta satu pun demo software. Saat Anda akhirnya bicara dengan vendor, pertanyaan Anda akan lebih tajam, karena Anda benar-benar tahu apa yang perlu diotomatisasi, alih-alih berharap software-nya yang akan mencari tahu sendiri.

Kesimpulan

Software tidak bisa memperbaiki proses yang tidak ia ciptakan. Jika SOP Anda tidak terdokumentasi, tidak konsisten, atau hanya bertahan lewat pengetahuan tribal segelintir orang, membeli sistem hanya memindahkan kekacauan itu ke tempat yang lebih mahal dan lebih sulit diubah. Luangkan 90 menit untuk memetakan dan menyederhanakan lebih dulu. Software yang Anda beli sesudahnya akan lebih murah, lebih cepat diadopsi, dan benar-benar menyelesaikan masalah yang membuat Anda membelinya.

Jika Anda ingin sudut pandang kedua tentang apakah proses Anda sudah siap untuk diotomatisasi, percakapan scoping semacam itu justru menjadi titik awal saya bersama klien baru sebagai technology partner.