Pemetaan Proses Bisnis Sebelum Membangun Software: Dari Peta As-Is ke Kebutuhan Sistem

Banyak proyek software dimulai dari daftar fitur: perlu modul pembelian, perlu laporan stok, perlu persetujuan berjenjang. Daftar ini terlihat lengkap, tetapi sering melewatkan pertanyaan yang lebih mendasar: bagaimana sebenarnya pekerjaan itu berjalan hari ini, siapa melakukan apa, di mana pekerjaan menunggu, dan bagian mana yang memang perlu diubah. Tanpa jawaban ini, software baru cenderung mendigitalkan kekacauan lama, atau sebaliknya memaksakan alur yang tidak cocok dengan kenyataan di lapangan.

Pemetaan proses bisnis adalah cara untuk menjawab pertanyaan itu sebelum satu baris kode ditulis. Artikel ini menjelaskan apa itu pemetaan proses, perbedaan peta kondisi saat ini dan kondisi yang diinginkan, cara menjalankan lokakarya pemetaan, notasi yang cukup untuk kebanyakan bisnis, serta cara mengubah peta menjadi kebutuhan software yang jelas.

Ringkasan

• Pemetaan proses menggambarkan langkah, pelaku, dokumen, keputusan, dan waktu tunggu dalam satu alur kerja
• Peta kondisi saat ini (as-is) menunjukkan kenyataan, peta kondisi yang diinginkan (to-be) menunjukkan rancangan perbaikan
• Pemborosan terbesar biasanya ada di waktu tunggu, input ulang data, dan persetujuan yang tidak perlu, bukan di kecepatan kerja
• Notasi swimlane sederhana sudah cukup untuk sebagian besar proyek; BPMN lengkap dipakai bila prosesnya rumit
• Peta to-be yang disepakati menjadi dasar dokumen kebutuhan, pengujian, dan pelatihan pengguna

Mengapa memetakan proses sebelum membangun software?

Salah satu penyebab umum proyek software gagal adalah kebutuhan yang tidak dipahami dengan benar. Pengguna meminta fitur berdasarkan masalah yang mereka rasakan, bukan berdasarkan alur kerja secara utuh. Bagian pembelian meminta formulir permintaan barang yang lebih cepat, padahal masalah sebenarnya adalah persetujuan yang menunggu tiga hari di meja manajer yang sedang dinas luar.

Pemetaan proses membuat masalah seperti ini terlihat. Ketika semua langkah digambar dari awal sampai akhir, tim bisa melihat di mana pekerjaan berhenti, di mana data diketik ulang, dan di mana keputusan diambil tanpa informasi yang cukup. Software kemudian dirancang untuk mengatasi titik-titik itu, bukan sekadar memindahkan formulir kertas ke layar.

Peta kondisi saat ini dan kondisi yang diinginkan

As-is: menggambar kenyataan

Peta as-is menggambarkan cara kerja hari ini, apa adanya, termasuk jalan pintas, pengecualian, dan pekerjaan di luar sistem seperti pesan WhatsApp atau spreadsheet pribadi. Godaan terbesar adalah menggambar proses sesuai prosedur tertulis, bukan sesuai kenyataan. Karena itu, peta as-is harus disusun bersama orang yang benar-benar mengerjakan prosesnya, bukan hanya oleh atasannya.

Untuk setiap langkah, catat siapa yang mengerjakan, input apa yang dibutuhkan, output apa yang dihasilkan, sistem atau dokumen apa yang dipakai, berapa lama dikerjakan, dan berapa lama menunggu sebelum langkah berikutnya. Data waktu tunggu inilah yang paling sering membuka mata.

To-be: merancang perbaikan

Peta to-be menggambarkan alur kerja yang diinginkan setelah perbaikan dan software baru diterapkan. Bukan semua perbaikan harus berupa software. Kadang yang dibutuhkan adalah menghapus langkah yang tidak perlu, menggabungkan dua persetujuan, atau memindahkan keputusan ke orang yang lebih dekat dengan pekerjaannya. Software kemudian mendukung alur yang sudah disederhanakan, sehingga lebih murah dibangun dan lebih mudah dipakai.

Menjalankan lokakarya pemetaan

1. 01Pilih satu proses dengan batas yang jelas, misalnya dari permintaan pembelian sampai pembayaran pemasok, bukan seluruh operasional sekaligus
2. 02Undang perwakilan setiap peran yang terlibat, termasuk staf pelaksana, bukan hanya kepala bagian
3. 03Mulai dari pemicu proses dan hasil akhirnya, lalu isi langkah di antaranya secara berurutan
4. 04Gunakan kertas tempel atau papan digital agar langkah mudah dipindah dan diperdebatkan
5. 05Tandai setiap titik masalah: menunggu, input ulang, kesalahan berulang, keputusan tanpa data
6. 06Kumpulkan contoh dokumen nyata, seperti formulir, laporan, dan tangkapan layar, untuk setiap langkah
7. 07Tutup dengan daftar masalah yang diprioritaskan dan pemilik untuk merancang peta to-be

Lokakarya dua sampai tiga jam per proses biasanya cukup untuk peta as-is awal. Peta ini kemudian divalidasi dengan mengikuti beberapa transaksi nyata dari awal sampai akhir, karena orang sering lupa langkah yang mereka kerjakan secara otomatis. Untuk proses lintas departemen, seperti alur approval pembelian, sesi tambahan dengan semua pihak sering diperlukan untuk menyepakati serah terima.

Contoh: proses pembelian di perusahaan distribusi

Sebuah distributor ingin membangun modul pembelian karena merasa prosesnya lambat. Lokakarya memetakan sebelas langkah dari permintaan gudang sampai pesanan dikirim ke pemasok. Waktu kerja seluruh langkah ternyata kurang dari dua jam, tetapi rata-rata waktu dari awal sampai akhir mencapai enam hari. Sebagian besar waktu habis untuk menunggu: permintaan menunggu dikumpulkan setiap Senin, lalu menunggu tanda tangan manajer gudang, kepala pembelian, dan direktur keuangan, meskipun nilai sebagian besar pesanan kecil. Data barang juga diketik tiga kali, dari formulir kertas ke spreadsheet lalu ke sistem akuntansi.

Peta to-be yang disepakati menghapus pengumpulan mingguan, menetapkan persetujuan berdasarkan nilai sehingga pesanan kecil cukup disetujui satu orang, dan membuat permintaan langsung dibuat di sistem oleh gudang. Software yang dibangun menjadi lebih sederhana dari rencana awal, dan target waktu proses turun menjadi satu hari. Tanpa pemetaan, tim mungkin hanya membuat formulir digital yang mempercepat dua jam kerja dan membiarkan enam hari menunggu tetap ada.

Notasi yang cukup untuk kebanyakan bisnis

Ada banyak notasi pemetaan proses. Untuk sebagian besar proyek bisnis, diagram swimlane sederhana sudah cukup: setiap peran atau departemen mendapat satu jalur horizontal, langkah digambar sebagai kotak, keputusan sebagai belah ketupat, dan panah menunjukkan urutan. Serah terima antar jalur langsung terlihat, dan di sanalah biasanya masalah berada.

BPMN, standar notasi proses bisnis yang lebih lengkap, berguna ketika proses memiliki banyak cabang, peristiwa berbasis waktu, pengecualian, atau akan dijalankan langsung oleh mesin alur kerja. Namun notasi yang terlalu rinci membuat peta sulit dibaca oleh pengguna bisnis. Prinsipnya, pilih notasi yang dapat dipahami semua peserta lokakarya, lalu tambahkan detail teknis hanya di dokumen untuk tim pengembang.

Pemborosan yang paling sering ditemukan

• Data diketik ulang dari satu sistem atau dokumen ke yang lain, menimbulkan kesalahan dan memakan waktu
• Persetujuan berlapis untuk transaksi bernilai kecil yang jarang ditolak
• Pekerjaan menunggu orang yang sedang tidak di tempat karena tidak ada delegasi
• Laporan yang disusun manual setiap minggu padahal datanya sudah ada di sistem
• Informasi status yang hanya bisa diketahui dengan menelepon atau mengirim pesan
• Pengecekan ganda oleh dua bagian yang tidak tahu bagian lain sudah memeriksa

Banyak pemborosan ini dapat dikurangi dengan otomatisasi input data dari dokumen, otomatisasi laporan rutin, atau integrasi antar sistem, tetapi solusinya baru terlihat jelas setelah prosesnya terpetakan.

Dari peta proses menjadi kebutuhan software

Peta to-be yang disepakati adalah bahan terbaik untuk menyusun dokumen kebutuhan software. Setiap langkah yang didukung sistem diterjemahkan menjadi kebutuhan: layar atau formulir apa yang dibutuhkan, data apa yang dicatat, aturan apa yang berlaku, notifikasi apa yang dikirim, dan siapa yang berhak melakukan langkah itu. Setiap keputusan di peta menjadi aturan bisnis yang harus diuji.

Peta yang sama juga dipakai di tahap akhir proyek. Skenario uji penerimaan pengguna (UAT) disusun dengan mengikuti alur di peta, termasuk jalur pengecualian. Materi pelatihan pengguna pun lebih mudah dipahami karena menjelaskan alur kerja, bukan sekadar tombol di layar. Dengan begitu, peta proses menjadi benang merah dari analisis sampai peluncuran.

Mengukur hasilnya

Karena peta as-is mencatat waktu kerja dan waktu tunggu, perusahaan memiliki dasar untuk mengukur dampak software baru. Misalnya, waktu dari permintaan pembelian sampai pesanan terkirim ke pemasok turun dari lima hari menjadi satu hari, atau jumlah input ulang data berkurang dari empat kali menjadi sekali. Angka seperti ini jauh lebih meyakinkan bagi manajemen daripada sekadar menyatakan bahwa sistem sudah berjalan.

Pertanyaan yang sering diajukan

Siapa yang sebaiknya memimpin pemetaan proses? Idealnya seseorang yang netral dan memahami bisnis maupun teknologi, misalnya analis bisnis dari tim internal atau dari vendor. Yang penting, pemilik proses dari sisi bisnis ikut bertanggung jawab atas hasilnya.

Apakah pemetaan proses memperlambat proyek? Pemetaan menambah beberapa minggu di awal, tetapi biasanya menghemat jauh lebih banyak waktu dengan mengurangi perubahan kebutuhan di tengah jalan dan fitur yang dibangun tetapi tidak dipakai.

Perlukah memetakan semua proses perusahaan? Tidak. Mulailah dari proses yang akan disentuh software baru atau yang paling sering menimbulkan masalah. Pemetaan bisa diperluas bertahap, sejalan dengan implementasi bertahap.

Bagaimana jika setiap cabang punya cara kerja berbeda? Petakan beberapa variasi, lalu sepakati satu proses standar dengan pengecualian yang memang diperlukan. Standarisasi ini sering menjadi manfaat terbesar, bahkan sebelum software diterapkan.

Alat apa yang dipakai untuk memetakan proses? Untuk lokakarya, kertas tempel dan papan tulis atau papan digital kolaboratif sudah cukup. Setelah disepakati, peta dapat dirapikan di aplikasi diagram agar mudah dibagikan dan diperbarui. Yang lebih penting dari alatnya adalah peta disimpan di tempat yang mudah ditemukan, diberi tanggal, dan diperbarui ketika proses berubah, sehingga tetap menjadi acuan saat sistem dikembangkan lebih lanjut atau saat karyawan baru bergabung.

Kesimpulan

Pemetaan proses bisnis adalah investasi kecil yang melindungi investasi besar dalam software. Dengan memahami kenyataan lewat peta as-is, menyederhanakan alur lewat peta to-be, dan menerjemahkan peta itu menjadi kebutuhan, pengujian, dan pelatihan, perusahaan membangun software yang memecahkan masalah sebenarnya. Hasilnya adalah sistem yang lebih sederhana, pengguna yang lebih cepat menerima perubahan, dan dampak yang dapat diukur dengan angka.