BPMN, singkatan dari Business Process Model and Notation, adalah notasi standar untuk menggambarkan bagaimana suatu proses berjalan. Pada retur B2B, BPMN membantu tim menjawab pertanyaan yang menentukan perilaku sistem: ke mana kasus bergerak saat bukti tidak lengkap, siapa yang menerima hasil inspeksi, dan apa yang terjadi ketika masa klarifikasi habis.
Simbol BPMN yang Perlu Dipahami Tim Bisnis
Spesifikasi BPMN 2.0.2 dari OMG menjadi rujukan untuk arti elemen dan penghubungnya. Mulailah dari unsur yang diperlukan untuk menjelaskan keputusan, lalu tambah detail jika mengubah perilaku alur.
- Event menggambarkan sesuatu yang terjadi, seperti permintaan diterima atau waktu klarifikasi berakhir.
- Activity menggambarkan pekerjaan, seperti memeriksa bukti atau menyampaikan keputusan. Gunakan kata kerja yang menunjukkan hasil kerja.
- Gateway mengatur pemisahan atau penggabungan jalur. Untuk pertanyaan “Bukti lengkap?”, gateway eksklusif cocok bila hanya satu jalur yang diambil pada satu waktu.
- Sequence flow menunjukkan urutan dalam satu proses, termasuk antar-lane di dalam pool yang sama. Message flow menggambarkan komunikasi antara peserta yang berbeda pool.
Contoh BPMN: Bukti Retur Tidak Lengkap
Dalam skenario ilustratif ini, perusahaan menerima retur hanya setelah bukti minimum tersedia, tetapi memberi kesempatan pelanggan melengkapinya. Model berikut dapat diterjemahkan ke diagram dengan pool perusahaan dan pool pelanggan. Langkah internal perusahaan memakai sequence flow; pertukaran permintaan, bukti, dan pemberitahuan ke pelanggan memakai message flow.
- Permintaan diterima. Sistem membuat ID retur dan mengaitkannya dengan pesanan jika rujukannya tersedia. Petugas menjalankan aktivitas “Periksa Bukti”.
- Gateway “Bukti lengkap?” Jika ya, kasus menuju pemeriksaan kelayakan. Jika tidak, petugas mengirim permintaan bukti tambahan, lalu kasus masuk tahap menunggu respons.
- Tunggu salah satu kejadian. Dari tahap menunggu, tim dapat memodelkan pilihan yang dipicu kejadian: pesan bukti baru datang atau batas waktu tercapai. Bila bukti masuk, kembali ke pemeriksaan. Jika batas waktu tercapai lebih dulu, tutup permintaan dengan alasan dan informasikan cara mengajukannya kembali sesuai aturan.
- Keluar dengan hasil yang nyata. Akhiri setelah keputusan disampaikan. Bila penggantian atau refund perlu dieksekusi, buat rujukan tugas lanjutan pada sistem terkait.
Bedakan gateway keputusan dari gateway berbasis kejadian: pertanyaan “Bukti lengkap?” dijawab menggunakan data yang sudah tersedia, sedangkan menunggu pesan atau timer bergantung pada kejadian berikutnya. Perbedaan itu menentukan apa yang harus dicatat dan diuji pada sistem.
Dari Diagram ke Pengujian Sistem
Tulis Kondisi Cabang dalam Bahasa Operasional
Ubah label “lengkap” menjadi syarat yang dapat diperiksa: referensi transaksi tersedia, barang dapat diidentifikasi, dan bukti memenuhi ketentuan jenis klaim. Catat siapa yang menentukan kelengkapan bila informasi bertentangan. Jangan menampilkan nominal tenggat di diagram bila perusahaan belum menyepakatinya.
Uji Kejadian yang Datang Terlambat atau Berulang
Jalankan contoh permintaan lengkap, bukti ditambahkan sebelum tenggat, tenggat habis, dan lampiran yang masuk setelah kasus ditutup. Tambahkan skenario pesan terkirim dua kali: sistem dapat menyimpan riwayat yang sesuai tanpa membuka dua kasus untuk transaksi yang sama. Sepakati apakah kasus terlambat dibuka kembali atau dibuat sebagai permintaan baru dengan referensi ke kasus lama.
Kapan Diagram Perlu Dibawa ke Tim Integrasi?
Periksa dulu masukan dan keluaran minimum dalam SIPOC. Jika kebuntuan terletak pada siapa yang boleh memutuskan, gunakan RACI matrix untuk menetapkan pemilik keputusan.
Bawa diagram saat status berpindah antara portal pelanggan, gudang, dan ERP. Siapkan ID yang dipakai bersama, sumber kebenaran tiap status, dan tindakan jika notifikasi gagal. Bahas kebutuhan melalui layanan integrasi sistem Layana.ID atau diskusikan contoh alurnya dengan satu skenario normal dan satu pengecualian yang sudah disamarkan.