Cara Memetakan Alur Kerja Bisnis Sebelum Didigitalkan

Bayangkan sebuah pesanan sudah disetujui pelanggan, tetapi barang belum dikirim karena staf gudang belum menerima informasi. Penjualan merasa order sudah lengkap, gudang menunggu rincian barang, sementara admin mengira pesan sudah diteruskan lewat grup WhatsApp. Masing-masing orang mungkin merasa telah menyelesaikan bagiannya. Masalahnya ada di perpindahan pekerjaan di antara mereka.

Situasi seperti ini mudah terlewat ketika perusahaan langsung meminta developer membuat aplikasi. Permintaan yang terdengar sederhana, seperti “buatkan sistem order”, belum menjelaskan kapan order dianggap sah, siapa yang boleh mengubahnya, atau apa yang terjadi ketika barang tidak tersedia. Sebelum memilih fitur, petakan dulu alurnya.

Mulai dengan satu proses yang punya batas jelas

Jangan mencoba menggambar seluruh perusahaan dalam satu diagram. Pilih satu proses yang cukup sering terjadi dan punya titik awal serta akhir yang dapat dikenali. Contohnya, mulai dari pesanan pelanggan diterima sampai barang dikirim, dari barang datang sampai stok tersedia untuk dijual, atau dari transaksi selesai sampai pembayaran masuk ke rekening.

Tetapkan batas proses di awal. Untuk alur penjualan, misalnya, apakah proses dimulai ketika pelanggan bertanya, saat penawaran dikirim, atau ketika pelanggan menyetujui pesanan? Apakah proses berakhir ketika barang keluar dari gudang, ketika invoice terbit, atau setelah pembayaran diterima? Batas yang kabur membuat setiap bagian menggambar proses yang berbeda.

Panduan discovery GOV.UK menyarankan agar tim memahami masalah, konteks pengguna, batasan, dan cara mengukur keberhasilan sebelum berkomitmen membangun layanan. Prinsip itu juga berguna untuk sistem internal: jangan menganggap solusi teknologi sudah pasti benar sebelum persoalannya dipahami (GOV.UK, How the discovery phase works).

Amati pekerjaan nyata, bukan hanya SOP

SOP menunjukkan proses yang direncanakan. Untuk mengetahui proses yang berlangsung, ajak orang yang benar-benar mengerjakan tugasnya dan minta mereka menjelaskan satu transaksi terbaru dari awal sampai selesai. Bila memungkinkan, amati langsung cara mereka membuka file, mencari informasi, meminta persetujuan, dan memberi kabar kepada bagian berikutnya.

Catat bukti yang terlihat: file Excel yang dipakai, kolom yang selalu diisi, pesan yang perlu dicari kembali, formulir yang ditandatangani, serta sistem lain yang harus dibuka. Tanyakan juga apa yang dilakukan ketika kondisi tidak normal. Proses yang hanya bekerja saat semua data lengkap belum cukup menggambarkan kenyataan operasional.

Jangan langsung mengubah jawaban pengguna menjadi daftar fitur. Jika staf berkata, “Kami butuh notifikasi,” gali penyebabnya. Mungkin informasi tidak sampai ke bagian berikutnya, status pekerjaan tidak terlihat, atau tidak ada orang yang bertanggung jawab mengambil tindakan setelah order masuk. Notifikasi bisa membantu, tetapi persoalan utamanya mungkin penetapan tanggung jawab.

Catat enam unsur pada setiap langkah

Peta yang berguna harus menjawab siapa melakukan apa, dengan informasi apa, dan apa yang menyebabkan pekerjaan berpindah ke langkah berikutnya. Gunakan tabel kerja sederhana berikut ketika mewawancarai pengguna.

Unsur	Pertanyaan yang perlu dijawab	Contoh pada proses pesanan
Pemicu	Apa yang memulai pekerjaan?	Pelanggan menyetujui penawaran
Pelaksana	Siapa yang bertanggung jawab?	Staf penjualan membuat order
Data	Informasi apa yang diperlukan?	SKU, jumlah, harga, alamat, termin pembayaran
Keputusan	Kondisi apa yang menentukan cabang proses?	Stok tersedia atau perlu pengadaan
Serah terima	Siapa menerima pekerjaan berikutnya?	Gudang menerima daftar picking
Hasil	Apa bukti bahwa langkah selesai?	Barang dikirim dan nomor pengiriman tercatat

Satu langkah sebaiknya menggambarkan satu aktivitas yang dapat diamati. “Admin mengurus order” terlalu luas karena bisa mencakup pemeriksaan harga, pengecekan stok, pencetakan invoice, dan komunikasi dengan pelanggan. Pisahkan aktivitas yang memiliki pelaksana, data, atau keputusan berbeda.

Gambar kondisi sekarang sebelum merancang kondisi ideal

Peta kondisi saat ini sering disebut as-is. Gambarkan urutan aktual menggunakan kotak aktivitas, panah, dan titik keputusan. Jika beberapa peran terlibat, pisahkan diagram berdasarkan peran atau bagian, sering disebut swimlane, agar perpindahan tanggung jawab tampak jelas. Tidak perlu menggunakan notasi yang rumit bila tim belum terbiasa; yang penting semua orang membaca simbol dengan cara yang sama.

Tandai titik antrean, input berulang, persetujuan yang tertunda, dan data yang disalin dari satu tempat ke tempat lain. Beri perhatian pada situasi ketika dua orang merasa bertanggung jawab atas tugas yang sama, atau sebaliknya tidak ada orang yang mengambilnya. Peta harus mencerminkan pengecualian yang benar-benar terjadi, bukan hanya alur ideal.

Misalnya, jika 10 pesanan terakhir memperlihatkan bahwa dua pesanan tertunda karena alamat tidak lengkap, masalahnya mungkin bukan kecepatan gudang. Formulir order mungkin belum meminta informasi wajib atau belum memiliki cara mengembalikan data yang kurang kepada penjualan. Contoh ini merupakan ilustrasi cara membaca proses, bukan hasil studi terhadap perusahaan tertentu.

Pisahkan masalah proses dari masalah perangkat lunak

Setelah peta selesai, tanyakan apakah hambatan dapat dihilangkan dengan memperjelas aturan kerja, menggabungkan formulir, atau menetapkan satu penanggung jawab. Tidak semua masalah membutuhkan aplikasi khusus. Sebuah aturan penamaan file atau format nomor order yang konsisten mungkin cukup untuk beberapa tim kecil.

Jika masalah berulang berasal dari data yang tersebar, tidak adanya jejak perubahan, atau kebutuhan melihat status bersama secara langsung, perangkat lunak dapat menjadi bagian dari solusi. Tetap tulis kebutuhan pada tingkat hasil kerja, bukan fitur yang diinginkan. “Gudang dapat melihat order yang sudah disetujui tanpa menyalin chat” lebih dapat diuji daripada “buat dashboard modern”.

Rancang alur baru dan ukur apakah benar-benar lebih baik

Buat peta kondisi tujuan atau to-be hanya setelah hambatan utama disepakati. Untuk setiap perubahan, jelaskan apa yang dihilangkan, apa yang tetap, siapa yang bertanggung jawab, dan bagaimana pengecualian ditangani. Jika order akan ditolak ketika stok tidak cukup, tentukan siapa yang memberi pilihan kepada pelanggan dan apakah barang dapat dipesan terlebih dahulu.

Pilih beberapa ukuran yang sesuai dengan masalah awal. Bisa berupa waktu dari persetujuan order sampai diterima gudang, jumlah input ulang per pesanan, order yang tidak memiliki penanggung jawab, atau banyaknya koreksi setelah transaksi dibuat. Catat nilai awal sebelum perubahan agar tim tidak menilai keberhasilan hanya dari kesan pengguna.

Peta juga perlu diuji dengan orang yang menjalankan pekerjaan tersebut. Minta staf menelusuri transaksi biasa dan transaksi pengecualian menggunakan diagram baru. Jika mereka harus sering menjelaskan “biasanya kami melakukan hal lain”, berarti peta belum cukup akurat atau aturan baru belum diputuskan.

Siapkan bahan yang berguna untuk developer

Saat proses sudah dipahami, dokumentasikan diagram, definisi istilah, contoh data, aturan keputusan, peran dan hak akses, serta kriteria bahwa pekerjaan dianggap selesai. Tambahkan daftar hal yang belum disepakati. Pertanyaan terbuka seperti aturan diskon, transaksi batal, atau stok dalam perjalanan lebih baik dicatat daripada dibiarkan menjadi asumsi pengembang.

Jika proses tersebut akan dijadikan aplikasi, bawa satu contoh kasus normal dan beberapa kasus pengecualian ketika berdiskusi dengan digitalisasi.app atau penyedia yang Anda evaluasi. Bahan ini membantu diskusi berpindah dari permintaan fitur yang abstrak menuju alur kerja yang dapat ditinjau, diperkirakan, dan diuji.

Referensi

• GOV.UK Service Manual, How the discovery phase works
• GOV.UK Service Manual, Map and understand a user's whole problem
• GOV.UK Service Standard, Understand users and their needs

Referensi diakses 25 Oktober 2026.