Hampir semua proyek otomatisasi yang saya lihat gagal punya satu kesamaan: tidak ada yang memetakan prosesnya sebelum menyentuh software. Tim langsung lompat ke "ayo kita bikin sistem untuk ini," dan enam bulan kemudian mereka punya cara yang cepat dan mahal untuk melakukan sesuatu yang sebenarnya tidak perlu dilakukan sama sekali. Process mapping sebelum otomatisasi adalah asuransi termurah yang bisa Anda beli dalam sebuah proyek, dan biayanya cuma satu sore, bukan satu baris anggaran.
Insting untuk otomatisasi biasanya sudah benar. Yang salah adalah urutannya. Kalau Anda mengotomatisasi proses yang penuh workaround, pengecualian, dan langkah-langkah yang sudah tidak ada yang ingat lagi alasannya, hasilnya bukan proses yang lebih baik. Anda cuma dapat kekacauan yang sama, hanya lebih cepat dan lebih sulit diubah, karena sekarang sudah terpatri dalam software, bukan lagi kebiasaan orang.
Saya pernah melihat sebuah jaringan ritel di Tangerang menghabiskan uang sungguhan untuk membangun aplikasi approval workflow yang dengan setia mereplikasi proses purchase order dengan empat tanda tangan. Tidak ada yang pernah bertanya kenapa butuh empat tanda tangan. Ternyata itu aturan pencegahan fraud dari satu insiden delapan tahun lalu, dan tiga dari empat approver cuma stempel-cap tanpa membaca. Software-nya membuat proses stempel-cap itu jadi instan. Itu bukan efisiensi, itu teater yang mahal.
Kenapa pemetaan harus lebih dulu
Process map memaksa Anda melihat alur kerja sebagai langkah, serah terima, dan waktu tunggu, bukan sebagai "ya begini caranya dari dulu." Begitu sudah tertulis di kertas (atau dinding penuh sticky notes), pola-pola yang tadinya tak terlihat karena hanya hidup di kepala orang jadi kelihatan jelas:
- Langkah yang ada karena satu insiden buruk bertahun-tahun lalu, tidak pernah ditinjau ulang
- Approval yang menambah waktu tunggu tapi tidak ada keputusan sesungguhnya
- Data yang diinput dua kali ke dua sistem karena tidak ada yang menghubungkannya
- Serah terima di mana satu orang menunggu orang lain untuk informasi yang sebenarnya bisa disediakan lebih awal
Semua ini tidak butuh konsultan atau tools canggih. Yang dibutuhkan hanya menuliskan langkah-langkah yang sesungguhnya terjadi dan bertanya, secara terbuka, di ruangan bersama orang-orang yang benar-benar mengerjakan proses itu, "kenapa langkah ini ada?"
Metode satu sore
Ini versi yang benar-benar saya pakai dengan klien, dan cukup untuk sesi setengah hari bersama tim yang menjalankan proses tersebut, bukan cuma manajernya.
- Tuliskan setiap langkah secara berurutan. Sticky notes, whiteboard, atau shared doc. Satu langkah per catatan. Jangan lewatkan langkah hanya karena terasa "sudah jelas."
- Tandai siapa yang mengerjakan tiap langkah dan siapa yang mereka tunggu. Gambar panah dari langkah ke langkah untuk menunjukkan serah terima. Di sinilah antrean dan waktu mati terlihat.
- Lingkari setiap langkah yang ada hanya karena kesalahan masa lalu atau preferensi manajer yang sudah tidak ada. Tanya langsung ke ruangan: apakah ada yang tahu kenapa langkah ini ada? Keheningan adalah sinyal.
- Catat waktu tunggu, bukan cuma waktu kerja. Sebagian besar keluhan proses bukan soal pekerjaannya sendiri, tapi soal menunggu antar langkah. Formulir yang butuh lima menit diisi tapi menunggu tiga hari untuk ditandatangani adalah proses tiga hari, bukan proses lima menit.
- Hapus dulu sebelum digitalisasi. Untuk setiap langkah yang dilingkari, putuskan: hilangkan, gabungkan, atau pertahankan dengan alasan yang terdokumentasi. Baru setelah tahap ini Anda memutuskan apa yang akan diotomatisasi.
Dari pengalaman saya, latihan ini menghilangkan 25-35% langkah sebelum satu baris kode pun ditulis. Itu bukan angka kecil. Itu sepertiga dari anggaran software Anda ke depan yang baru saja Anda hemat, karena Anda tidak lagi membayar untuk mempercepat pekerjaan yang seharusnya tidak perlu ada.
Contohnya dalam alur kerja nyata
Ambil contoh yang umum: permintaan pembelian di distributor skala menengah. Versi yang belum dipetakan terlihat sederhana di kepala seseorang: "karyawan mengajukan, manajer menyetujui, purchasing membeli." Setelah dipetakan secara jujur, sering kali terlihat seperti ini:
| Langkah | Siapa | Waktu Tunggu | Alasan Keberadaannya |
|---|---|---|---|
| Isi formulir kertas | Pemohon | tidak ada | Warisan dari era sebelum email |
| Bawa formulir ke manajer | Pemohon | jam-hari | Tidak ada routing digital |
| Manajer menyetujui | Manajer | hari (dalam rapat) | Keputusan penilaian yang genuine |
| Input ulang ke sistem purchasing | Admin | hari (antrean) | Sistem tidak pernah terhubung |
| Approval kedua di atas 5 juta rupiah | Finance | hari | Kontrol nyata, jarang terpicu |
| Pembelian dilakukan | Purchasing | - | Pekerjaan sesungguhnya |
Setelah dipetakan, jelas terlihat bahwa langkah input ulang adalah target otomatisasi yang sebenarnya, dan langkah "bawa formulir ke manajer" cukup diselesaikan dengan telepon atau formulir web, bukan aplikasi. Ini disiplin yang sama yang dibahas di Automating Repetitive Back Office Tasks: Where to Start: temukan dulu langkah yang murni friksi sebelum membangun apa pun.
Saat Anda siap mengotomatisasi
Begitu peta sudah bersih, percakapan soal otomatisasi berubah total. Alih-alih "buatkan sistem seperti proses kami sekarang," jadinya "ini tiga langkah yang benar-benar butuh software, dan ini data yang harus mengalir di antara ketiganya." Itu proyek yang scoped, bisa dibangun, dan jujur saja jauh lebih murah. Vendor bisa memberi quote lebih cepat dan lebih akurat untuk proses yang bersih dibanding yang berantakan, karena lebih sedikit ambiguitas yang harus mereka hitung sebagai risiko.
Ini juga melindungi Anda dari jebakan spesifik: proses lama yang dulu dibangun mengikuti keterbatasan software lama. Kalau Anda memetakan alur kerja yang sudah berjalan lewat sistem yang tim Anda sudah kelewat besar untuknya, latihan pemetaan ini juga akan mengungkapnya, dan ada baiknya membaca The Hidden Cost of Legacy Systems in Your Business sebagai pendamping.
Intinya
Jangan beli atau bangun software otomatisasi sebelum Anda memetakan prosesnya di atas kertas dan menghapus langkah-langkah yang tidak layak dipertahankan. Satu sore dengan sticky notes dan orang-orang yang benar-benar mengerjakan pekerjaan itu akan menghemat berbulan-bulan rework mahal dan sistem yang cuma mempercepat hal yang salah. Kalau Anda ingin sudut pandang kedua atas sebuah proses sebelum berkomitmen anggaran untuk mengotomatisasinya, itu justru percakapan yang layak dilakukan lebih awal, bukan setelah invoice datang.