Petakan Prosesnya Dulu, Baru Otomatisasi

·6 menit baca·Ervandra Halim

Ringkasan

Hampir semua proyek otomatisasi gagal karena satu sebab yang sama: tidak ada yang memetakan prosesnya sebelum software dibangun. Dari pengalaman saya menangani proyek semacam ini, process mapping sebelum otomatisasi berarti menuliskan setiap langkah, serah terima, dan waktu tunggu, lalu menghapus langkah yang cuma bertahan karena kebiasaan. Dilakukan lebih dulu, latihan ini biasanya menghilangkan 25-35% langkah sebelum satu baris kode pun ditulis, sehingga sistem yang benar-benar perlu dibangun jadi jauh lebih kecil.

  • Mengotomatisasi proses yang sudah rusak cuma membuat kekacauan yang sama jadi lebih cepat dan lebih sulit diubah, karena workaround-nya jadi terpatri dalam software, bukan lagi kebiasaan yang masih bisa dipertanyakan orang.
  • Sesi pemetaan setengah hari bersama tim yang benar-benar mengerjakan prosesnya, bukan cuma manajernya, sudah cukup untuk mengungkap langkah-langkah yang tidak bisa dijelaskan siapa pun, seperti proses approval empat tanda tangan yang ternyata berasal dari satu insiden fraud delapan tahun lalu.
  • Keputusan untuk menghapus, menggabungkan, atau mempertahankan sebuah langkah diambil sebelum lingkup otomatisasi ditentukan, dan itu yang membuat vendor bisa memberi quote lebih cepat dan lebih akurat untuk proses yang bersih dibanding yang berantakan.

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.

"Itu bukan efisiensi, itu teater yang mahal."

Ervandra Halim, konsultan teknologi untuk operasional bisnis

Kenapa pemetaan harus dilakukan lebih dulu?

Pemetaan harus lebih dulu karena 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 di dinding penuh sticky notes, pola-pola yang tadinya tak terlihat karena cuma 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.

  1. Tuliskan setiap langkah secara berurutan. Sticky notes, whiteboard, atau shared doc. Satu langkah per catatan. Jangan lewatkan langkah hanya karena terasa "sudah jelas."
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Seperti apa contohnya dalam alur kerja nyata?

Permintaan pembelian di distributor skala menengah adalah contoh nyata yang bagus untuk melihat apa yang sebenarnya diungkap pemetaan. Versi yang belum dipetakan terlihat sederhana di kepala seseorang: "karyawan mengajukan, manajer menyetujui, purchasing membeli." Setelah dipetakan secara jujur, dengan setiap serah terima dan waktu tunggu ditampilkan, hasilnya sering 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.

Bagaimana Anda tahu kapan siap mengotomatisasi?

Kebersihan peta itu sendiri sinyalnya: 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.

pemetaan prosesotomatisasioperasionalalur kerjaefisiensi

Pertanyaan yang sering diajukan

Bagaimana kalau di ruangan tidak ada yang tahu kenapa suatu langkah ada?

Anggap keheningan itu sendiri sebagai sinyal, bukan pertanyaan yang perlu dicari jawabannya nanti. Kalau Anda bertanya kenapa sebuah langkah ada dan tidak ada yang menjawab, tandai langkah itu sebagai kandidat untuk dihapus, bukan diasumsikan penting. Pada kasus jaringan ritel di Tangerang, pertanyaan itu akan mengungkap bahwa tiga dari empat tanda tangan hanya ada karena satu insiden fraud delapan tahun lalu yang tidak pernah ditinjau ulang.

Sebaiknya pemetaan dilakukan bersama manajer atau bersama tim yang mengerjakan prosesnya?

Libatkan orang-orang yang benar-benar mengerjakan pekerjaannya, bukan cuma manajer mereka. Manajer sering hanya tahu proses sebagaimana didokumentasikan atau sebagaimana yang mereka asumsikan berjalan, sementara tim yang menjalani serah terima dan waktu tunggu setiap hari tahu workaround dan waktu mati yang sesungguhnya. Pemetaan tanpa mereka cuma menghasilkan peta asumsi manajemen, bukan alur kerja yang sebenarnya.

Bagaimana kalau proses yang dipetakan ternyata berjalan di atas sistem lama yang sudah usang?

Latihan pemetaan akan mengungkap itu sebagai masalah tersendiri yang perlu ditangani berdampingan dengan otomatisasi. Kalau alur kerja yang Anda petakan sudah berjalan lewat software yang tim Anda kelewat besar untuknya, keterbatasan itu akan ikut terlihat, dan sebaiknya diperlakukan sebagai keputusan sendiri, bukan dimasukkan begitu saja ke lingkup otomatisasi yang sedang Anda hitung.

Apakah menghapus langkah berarti proyek otomatisasinya jadi lebih kecil?

Ya, dan justru itu intinya. Setelah langkah-langkah yang tidak layak dipertahankan dihapus, lingkup otomatisasi yang tersisa menyempit jadi hanya beberapa langkah yang benar-benar butuh software dan data yang harus mengalir di antaranya, dan itu yang membuat vendor bisa memberi quote lebih cepat dan lebih akurat untuk proses yang bersih dibanding yang berantakan.

Ervandra Halim

Ervandra Halim

CPTO & Principal Architect

Ervandra Halim membantu owner dan leader memodernisasi operasional dan menerapkan AI setiap hari. Ia partner dengan beberapa bisnis dalam satu waktu, sebagian besar lewat referral.

Lanjut membaca

Digital Strategy

Kapan TIDAK Mengotomatiskan: Daftar Periksa Pelawan

Mengetahui kapan tidak mengotomatisasi akan menghemat lebih banyak uang daripada mengotomatisasi segalanya. Volume rendah, varian tinggi, dan momen hubungan adalah milik manusia.

·5 min read

Digital Strategy

Bereskan Data Anda Sebelum Membeli AI

Kualitas data untuk AI adalah prasyarat yang tidak menarik tapi sering dilewatkan. Bagaimana data pelanggan yang berantakan dan spreadsheet duplikat diam-diam menggagalkan proyek AI.

·5 min read

© 2011–2026 Ervandra Halim