Lokakarya pemetaan proses mempertemukan orang-orang yang menjalankan alur kerja untuk menjelaskan apa yang benar-benar terjadi dari awal yang ditentukan hingga akhir yang ditentukan. Hasil yang berguna adalah peta kondisi saat ini yang dipahami bersama, dengan keputusan, serah terima, penundaan, dan pengecualian terlihat jelas. Usulan perbaikan dibuat setelah peserta memeriksa apakah peta tersebut sesuai dengan pekerjaan nyata.
Lokakarya dapat gagal meskipun menghasilkan diagram yang menarik. Jika peta menunjukkan proses yang diharapkan semua orang, peta itu tidak dapat menjelaskan mengapa pekerjaan tersendat. Mulailah dengan satu kasus baru-baru ini, libatkan orang yang menanganinya, dan bedakan fakta tercatat dari asumsi.
Panduan flowchart ASQ menyarankan untuk menetapkan batas, mengurutkan aktivitas, dan meninjau hasilnya bersama orang-orang yang terlibat. Agenda di bawah menerapkan prinsip tersebut dalam lokakarya tim. Ini praktik yang disarankan, bukan metode sertifikasi formal.
Pilih batas yang dapat ditangani dalam satu rapat
“Petakan proses pengiriman kami” terlalu luas untuk sesi pertama. “Dari saat pelanggan melaporkan kesalahan tagihan hingga koreksinya dikonfirmasi” memberi peserta titik awal dan akhir yang mudah dikenali. Tuliskan pemicu dan hasil akhir dalam undangan.
Pilih satu kasus rutin yang baru terjadi dan satu pengecualian yang bermakna. Kasus rutin menunjukkan alur utama; pengecualian memperlihatkan keputusan atau putaran yang mungkin tidak tampak pada diagram yang rapi. Hapus identitas pelanggan dan informasi pribadi lain yang tidak diperlukan dari bukti yang dibagikan.
Undang perwakilan orang-orang yang mengerjakan proses, termasuk orang yang menerima hasil akhirnya. Kepala departemen mungkin mengetahui proses yang direncanakan, sedangkan spesialis dukungan mengetahui spreadsheet yang membuatnya berjalan. Jika peran penting tidak bisa hadir, tandai bagian peta tersebut sebagai belum terverifikasi alih-alih mengisinya dengan asumsi manajerial.
Agenda lokakarya pemetaan proses 75 menit
| Menit | Aktivitas | Hasil |
|---|---|---|
| 0–10 | Pastikan pemicu, akhir, dan contoh kasus | Pernyataan ruang lingkup |
| 10–25 | Rekonstruksi kasus secara berurutan | Aktivitas yang benar-benar dilakukan |
| 25–40 | Tambahkan peran, keputusan, dan serah terima | Peta kondisi saat ini |
| 40–50 | Telusuri kasus melalui peta | Koreksi dan cabang yang hilang |
| 50–65 | Tandai waktu tunggu, pengerjaan ulang, dan ketidakpastian | Daftar masalah yang didukung bukti |
| 65–75 | Pilih satu perbaikan untuk diuji | Penanggung jawab, ukuran, dan tanggal tinjauan |
Gunakan label aktivitas yang konkret: “staf dukungan memeriksa catatan faktur,” bukan “triase.” Label harus menjelaskan apa yang terjadi, bukan sekadar menamai tahap. Gunakan panah untuk urutan dan tanda tanya untuk keputusan. Peta proses tidak membutuhkan notasi canggih untuk menunjukkan bagian yang belum memiliki penanggung jawab.
Jika menggunakan papan kolaborasi berbasis kolom, catat langkah dan bukti di sana, lalu pindahkan hubungan antarlangkah ke alat diagram bila perlu. Jangan menganggap semua papan mendukung konektor flowchart. Anda dapat memakai papan bersama Nextretro untuk mengumpulkan pengamatan dan keputusan lokakarya tanpa menganggapnya sebagai aplikasi pemodelan proses khusus.
Contoh terperinci: koreksi tagihan berputar dua kali
Bayangkan sebuah perusahaan langganan hipotetis. Pelanggan melaporkan tagihan yang salah. Tim dukungan memeriksa akun, mengirim permintaan ke bagian keuangan, menunggu klarifikasi, lalu mengonfirmasi koreksi. Langkah-langkah ini terlihat sederhana sampai peserta merekonstruksi kasus tertentu.
Bagian keuangan mengembalikan permintaan karena nomor faktur asli tidak dicantumkan. Tim dukungan lalu bertanya kepada pelanggan, membuka kembali permintaan, dan kembali menunggu. Serah terima kedua menggunakan rangkaian pesan yang berbeda, sehingga peninjau keuangan tidak melihat penjelasan pertama. Kasus itu kembali ke tim dukungan untuk kedua kalinya.
Kini peta memuat dua putaran yang berbeda: informasi yang hilang dan konteks yang terpencar. Tim tidak menulis tindakan umum seperti “perbaiki komunikasi.” Tim mencoba templat permintaan yang menyertakan referensi faktur dan menjaga klarifikasi berikutnya tetap terhubung dengan permintaan yang sama.
Contoh ini dibuat untuk menunjukkan metode, bukan membuktikan bahwa templat akan menyelesaikan semua keterlambatan tagihan. Tim tetap perlu memeriksa apakah kewenangan persetujuan, beban kerja, atau kendala lain lebih dominan dalam kasus sebenarnya.
Tambahkan bukti tanpa mengubah lokakarya menjadi audit
Gunakan tabel pendamping berikut di samping peta:
| Langkah | Bukti | Ketidakpastian | Pertanyaan yang perlu dijawab |
|---|---|---|---|
| Tim dukungan menyiapkan permintaan | Contoh permintaan tidak mencantumkan referensi faktur | Seberapa sering ini terjadi? | Tinjau sampel kecil yang batasnya ditentukan |
| Bagian keuangan meminta klarifikasi | Balasan memiliki cap waktu | Apakah permintaan terlihat sebelumnya? | Pastikan cara kerja antrean |
| Tim dukungan mengirim ulang | Ada rangkaian pesan terpisah | Apakah rangkaian baru memang diperlukan? | Tanyakan kepada pemilik alur kerja |
| Pelanggan menerima konfirmasi | Pesan penutupan | Apakah koreksi sesuai harapan? | Periksa bukti penerimaan |
Cap waktu menunjukkan kapan sesuatu tercatat, belum tentu kapan seseorang siap bertindak. Tanyakan cara sistem mencatat peristiwa sebelum menghitung waktu tunggu. Jika tidak ada data yang dapat diandalkan, tandai durasi tersebut sebagai pengamatan yang perlu diselidiki.
Jangan gunakan peta untuk membuat peringkat karyawan. Tujuannya adalah memahami pengaturan kerja. Menghitung secara terbuka berapa lama seseorang yang disebut namanya “menahan” suatu permintaan dapat menyembunyikan prioritas dan kapasitas, serta membuat orang enggan menjelaskan jalan pintas dengan jujur.
Pilih perubahan dan simpan kondisi awal
Pilih perubahan yang dapat disetujui orang-orang di ruangan atau mereka bawa kepada pengambil keputusan yang jelas. Catat mekanisme yang diharapkan: “Menyertakan referensi faktur seharusnya mengurangi klarifikasi sebelum bagian keuangan menilai permintaan.” Lalu tentukan apa yang akan diperiksa dan kapan.
Simpan peta kondisi saat ini sebelum menggambar keadaan yang diusulkan. Jika tidak, tim mungkin kehilangan bukti yang melandasi perubahan. Setelah uji coba, telusuri kembali alur yang sebenarnya. Templat penerimaan baru dapat menghapus satu putaran, tetapi menambah beban kerja tim dukungan.
Retrospektif cocok untuk meninjau uji coba itu bersama orang-orang yang sama. Gunakan ide retrospektif untuk format refleksi yang terstruktur dan sertakan bukti proses pada catatan keputusan.
Pertanyaan yang sering diajukan
Siapa yang perlu hadir dalam lokakarya pemetaan proses?
Libatkan orang yang menjalankan langkah utama, menerima hasil, dan mampu menyelesaikan keputusan proses. Tampilkan perspektif yang tidak hadir; jangan menganggap alur kerja departemen yang absen sudah diverifikasi.
Sebaiknya petakan proses saat ini atau proses mendatang terlebih dahulu?
Petakan proses saat ini terlebih dahulu jika tujuannya perbaikan. Periksa kesesuaiannya dengan kasus nyata sebelum merancang versi mendatang. Jika alurnya benar-benar baru, tandai peta sebagai usulan dan uji asumsinya.
Bagaimana jika alur kerja tidak muat dalam satu sesi?
Persempit batasnya menjadi satu bagian penting dan catat masukan serta keluarannya. Jadwalkan sesi lanjutan untuk bagian berikutnya daripada memaksakan seluruh organisasi ke dalam kotak-kotak yang samar.