Cara Membaca Intermediate Event
Intermediate Event adalah kejadian yang muncul di tengah alur proses — bukan awal, bukan akhir. Yang membuatnya sering salah dibaca adalah dua peran yang berlawanan: catching (menunggu/menerima) dan throwing (memicu/mengirim).
Cara Membedakan Catching dan Throwing Secara Visual
- Catching — ikon di dalam lingkaran tidak terisi (outline saja). Artinya proses menunggu sesuatu terjadi.
- Throwing — ikon di dalam lingkaran terisi penuh (solid). Artinya proses mengirim/memicu sesuatu.
Bedanya mirip await vs send() di pemrograman asinkron: satu menunggu input, satu mengirim output.
Template Reading Grammar
Catching (menunggu):
| Jenis | Template Kalimat |
|---|---|
| Message | "{lane} menunggu {message} sebelum melanjutkan" |
| Timer | "{lane} menunggu selama/sampai {durasi/tanggal}" |
| Signal | "{lane} menunggu sinyal '{signal}'" |
Throwing (memicu):
| Jenis | Template Kalimat |
|---|---|
| Message | "{lane} mengirimkan {message}" |
| Signal | "{lane} memancarkan sinyal '{signal}'" |
| Escalation | "{lane} mengeskalasi '{escalation}' ke pihak terkait" |
Diterapkan ke diagram di atas:
"Setelah Kirim Invoice, Finance menunggu Pembayaran Diterima sebelum melanjutkan. Selanjutnya Warehouse melakukan Siapkan Barang, lalu Warehouse mengirimkan Notifikasi Pengiriman."
Kenapa Arah Catching/Throwing Sering Terbalik
Kesalahan paling umum: pembuat diagram menggambar ikon throwing (solid) padahal maksudnya proses sedang menunggu, atau sebaliknya. Akibatnya, pembaca salah menyimpulkan siapa yang aktif menunggu dan siapa yang aktif mengirim.
:::tip Cek konsisten dengan konteks Kalau intermediate event ada tepat setelah sebuah task yang "menghasilkan sesuatu" (misalnya mengirim invoice), event berikutnya biasanya throwing (mengirim notifikasi terkait). Kalau intermediate event ada sebelum task yang "membutuhkan input dari luar" (misalnya menunggu approval), event itu biasanya catching. :::
Analogi Sehari-hari: Menunggu Paket vs Mengirim Paket
Untuk pembaca non-teknis, bedanya catching dan throwing seperti dua momen berbeda dalam berkirim paket:
- Catching = Anda menunggu kurir datang membawa paket. Aktivitas Anda berhenti sejenak; Anda tidak bisa melanjutkan (misalnya merakit barangnya) sebelum paket tiba.
- Throwing = Anda menyerahkan paket ke kurir untuk dikirim. Begitu diserahkan, urusan Anda selesai — Anda langsung lanjut ke kegiatan berikutnya tanpa menunggu paket sampai di tujuan.
Perhatikan asimetrinya: catching menghentikan alur sampai sesuatu datang; throwing tidak menghentikan apa pun — ia melempar lalu jalan terus. Asimetri inilah yang membuat salah baca catching/throwing berakibat salah paham total tentang di mana proses bisa "menggantung".
Contoh Kedua: Timer Intermediate sebagai Jeda yang Disengaja
Timer Intermediate Event (catching) sering dipakai sebagai jeda eksplisit. Contoh proses penagihan:
Task "Kirim Invoice" → Timer Intermediate "14 Hari" → Task "Kirim Surat Peringatan Pertama"
Dibaca: "Finance mengirim Invoice, lalu menunggu selama 14 hari, kemudian mengirim Surat Peringatan Pertama."
Pembaca kritis akan langsung bertanya: "bagaimana kalau pelanggan membayar di hari ke-5 — apakah surat peringatan tetap terkirim?" Pada diagram di atas, ya, tetap terkirim — tidak ada elemen yang membatalkan timer ketika pembayaran masuk. Kalau itu bukan perilaku yang diinginkan, diagramnya butuh Event-Based Gateway ("mana yang duluan: pembayaran masuk, atau 14 hari berlalu?") — lihat Cara Membaca Event-Based Gateway. Pertanyaan sederhana dari hasil pembacaan bisa mengungkap perbedaan desain yang besar.
Coba Sendiri
Di tengah proses pengiriman, ada Intermediate Event bergambar amplop terisi penuh (solid) berlabel "Konfirmasi Pesanan". Tepat setelahnya ada Task "Tunggu Balasan Pelanggan". Terjemahkan keduanya — ada yang tidak konsisten?
Lihat Jawaban
Amplop solid = throwing = "{lane} mengirimkan Konfirmasi Pesanan". Tapi task berikutnya bernama "Tunggu Balasan Pelanggan" — pekerjaan menunggu yang seharusnya dimodelkan sebagai catching event (amplop kosong) atau Receive Task, bukan Task biasa.
Kemungkinan besar pembuat diagram ingin: throwing "Kirim Konfirmasi" → catching "Balasan Diterima". Menulis "menunggu" sebagai Task biasa menyembunyikan fakta bahwa proses bisa menggantung di titik ini tanpa batas waktu — dan menghilangkan kesempatan memasang timer pengaman.
Pertanyaan Umum
Apa itu Link Event? Pasangan penanda "lompat" untuk diagram yang terlalu panjang: throwing link di ujung satu bagian, catching link dengan nama sama di awal bagian lain — mirip sambungan "bersambung ke halaman berikutnya". Tidak mengubah logika proses, hanya kerapian visual.
Bolehkah Intermediate Event tanpa label? Tidak disarankan. Tanpa label, template kalimatnya tidak bisa diisi — pembaca tahu proses menunggu/melempar sesuatu, tapi tidak tahu apa.
Apakah semua jenis event punya versi catching dan throwing? Tidak. Message, Signal, Link punya keduanya. Timer dan Conditional hanya catching (waktu dan kondisi tidak bisa "dilempar"). Error hanya muncul sebagai throwing di End Event dan catching di Boundary.
Lanjut ke Cara Membaca End Event, atau pelajari dasar notasinya di Intermediate Event.
Artikel Terkait
Sudah memahami konsep BPMN?
Wujudkan diagram Anda menjadi workflow automation nyata tanpa coding - dengan AlurKerja, platform BPM buatan Indonesia.