Ketika sebuah proses hanya hidup dalam kepala orang-orang yang menjalankannya, setiap orang cenderung menyimpan versinya sendiri-sendiri. Tim Finance mengira proses persetujuan berhenti di meja Manager Finance, sementara manager mengira dokumen itu sudah lama diteruskan ke Direktur Finance. Tidak ada yang berbohong, mereka hanya melihat potongan proses dari sudut pandang masing-masing, seperti orang buta yang meraba bagian tubuh gajah yang berbeda-beda.
Process mapping mengatasi masalah ini dengan cara yang sederhana namun powerful: memaksa semua sudut pandang itu dituangkan ke dalam satu gambar yang sama. Begitu proses digambar di atas kertas atau papan tulis, hal-hal yang selama ini tersembunyi mulai memperlihatkan diri, langkah yang ternyata dobel, dokumen yang bolak-balik tanpa alasan jelas, atau satu orang yang secara tidak sadar menjadi satu-satunya jalur yang harus dilewati semua keputusan.
Dua Alat yang Paling Sering Dipakai, dan Kenapa Keduanya Berbeda
Ada dua teknik visual yang paling umum digunakan untuk audit proses seperti flowchart dan swimlane diagram. Keduanya terlihat mirip pada pandangan pertama, sama-sama kotak dan panah, tapi masing-masing menjawab pertanyaan yang berbeda.
Flowchart menjawab pertanyaan, “Apa yang terjadi, dan dalam urutan seperti apa?” Ia menggambarkan alur logis sebuah proses: mulai dari titik awal, melewati serangkaian aktivitas dan keputusan, hingga berakhir di sebuah hasil. Kekuatan flowchart ada pada kesederhanaannya siapa pun, bahkan yang baru pertama kali melihat proses tersebut, bisa mengikuti alurnya dari kiri ke kanan atau atas ke bawah tanpa penjelasan tambahan yang rumit.
Contoh flowchart sederhana untuk proses penerbitan invoice. Perhatikan bagaimana satu titik keputusan, “Dokumen Lengkap & Sesuai?” bisa memicu perulangan (loop) yang, kalau sering terjadi, adalah tanda awal adanya bottleneck.
Namun flowchart punya kelemahan yang sering terlewat: ia tidak menceritakan siapa yang mengerjakan setiap langkah. Sebuah kotak bertuliskan “Review Dokumen” bisa saja dikerjakan oleh satu orang atau bolak-balik antara tiga departemen, flowchart biasa tidak akan menunjukkan perbedaan itu. Dan justru di titik perpindahan antar orang atau antar departemen itulah bottleneck paling sering bersembunyi.
Di sinilah swimlane diagram, kadang disebut juga cross-functional flowchart, mengambil peran. Bayangkan sebuah kolam renang dengan beberapa jalur (lane), dan setiap lane mewakili satu orang, tim, atau departemen. Aktivitas proses yang sama diletakkan di dalam lane sesuai siapa yang mengerjakannya, lalu dihubungkan dengan panah yang menunjukkan alur kerja sebagaimana biasa.
Hasilnya adalah gambar yang tidak hanya menunjukkan apa yang terjadi, tapi juga menunjukkan momen-momen ketika pekerjaan berpindah tangan, dari sales ke finance, dari finance ke legal, dan seterusnya.
Perpindahan tangan itulah yang layak dicurigai lebih dulu. Sebab hampir setiap kali sebuah pekerjaan berpindah dari satu lane ke lane lain, ada risiko jeda: dokumen menunggu di antrean orang lain, informasi harus dijelaskan ulang, atau, yang paling sering terjadi, tidak ada yang merasa terburu-buru karena “toh itu sekarang giliran tim sebelah”.
Diagram yang sama dilihat lewat swimlane. Dua panah diagonal berwarna merah menandai titik perpindahan lane, dari Sales ke Finance, dan dari Finance ke klien. Di dua titik itulah, dalam praktiknya, dokumen paling sering diam menunggu giliran diproses.
Membaca Gambar untuk Menemukan Titik Lemah
Setelah proses digambar, baik dalam bentuk flowchart maupun swimlane, langkah berikutnya adalah membacanya dengan mata yang berbeda, bukan lagi mata orang yang menjalankan proses sehari-hari, tapi mata seorang auditor yang mencurigai segalanya.
Ada beberapa pola yang biasanya muncul begitu gambar itu selesai dibuat:
- Pertama, perhatikan lane atau kotak mana yang paling sering dilewati panah. Kalau satu orang atau satu tim muncul berulang kali sebagai titik yang harus dilalui banyak proses berbeda, itu tanda kuat bahwa mereka telah menjadi jalur tunggal yang menahan banyak hal sekaligus, sering terjadi tanpa disadari, karena orang tersebut biasanya juga yang paling senior atau paling dipercaya.
- Kedua, perhatikan panah yang bolak-balik atau membentuk lingkaran. Sebuah dokumen yang dikirim, dikembalikan untuk revisi, dikirim lagi, dikembalikan lagi, pola zig-zag semacam ini di atas kertas biasanya mencerminkan sesuatu yang tidak jelas di dunia nyata: instruksi yang ambigu, standar kualitas yang tidak disepakati bersama, atau memang tidak ada kriteria selesai yang jelas sejak awal.
- Ketiga, perhatikan jeda waktu di setiap perpindahan lane, bukan hanya di dalam aktivitasnya. Sering kali waktu yang habis bukan karena pekerjaan itu sendiri sulit, melainkan karena dokumen menunggu giliran diperiksa. Kalau memungkinkan, tuliskan estimasi waktu di setiap panah perpindahan, bukan hanya di setiap kotak aktivitas. Aktivitas yang sebenarnya hanya butuh lima belas menit untuk dikerjakan, ternyata menunggu tiga hari sebelum ada yang sempat mengerjakannya.
Process mapping bukan proyek yang selesai begitu gambarnya jadi. Justru gambar itu baru berguna ketika dibawa kembali ke orang-orang yang menjalankan proses tersebut, lalu ditanyakan langsung, apakah gambar ini benar-benar mencerminkan yang terjadi di lapangan?
Sering kali jawabannya adalah tidak sepenuhnya. Ada langkah tidak resmi yang tidak tertulis di SOP mana pun tapi selalu dilakukan orang-orang untuk mengakali proses yang lambat. Ada pengecualian yang hanya diketahui satu dua orang senior. Justru celah antara “proses yang seharusnya” dan “proses yang benar-benar terjadi” ini sering menjadi sumber informasi paling berharga, karena ia menunjukkan di mana orang-orang sudah lebih dulu menyadari ada yang salah, jauh sebelum manajemen mulai bertanya.
Pada akhirnya, mengidentifikasi bottleneck bukan soal mencari kesalahan siapa, melainkan soal membuat sesuatu yang tadinya tak terlihat menjadi terlihat. Sekali sebuah alur kerja tergambar di atas kertas, dengan segala kotak, panah, dan lane-nya, organisasi tidak lagi berdebat berdasarkan asumsi atau ingatan yang berbeda-beda. Mereka berdebat, dan lebih penting lagi, memperbaiki, berdasarkan sesuatu yang sama-sama bisa dilihat.
