Parallel Gateway (AND)
Parallel Gateway memungkinkan proses berjalan di beberapa jalur secara bersamaan. Tidak ada kondisi, tidak ada keputusan — semua jalur selalu aktif. Ini adalah cara BPMN memodelkan pekerjaan yang bisa (dan sebaiknya) dilakukan secara paralel untuk mempersingkat waktu proses.
Simbol: Belah ketupat dengan tanda + di tengah
Dibaca sebagai: "Semua jalur aktif sekaligus" / "Kerjakan bersamaan"
Nama lain: AND Gateway, Parallel AND Gateway
Cara Kerja
Parallel Split (Diverging / Percabangan)
Ketika token mencapai Parallel Split, ia dipecah menjadi beberapa token — satu untuk setiap jalur keluar. Semua jalur diaktifkan secara bersamaan, tanpa syarat apapun.
→ [Siapkan Kontrak]
→ [Setup Akun Sistem]
[Mulai] ──◇+
→ [Konfigurasi Email]
→ [Assign Mentor]
Keempat task berjalan bersamaan. Tidak ada yang menunggu yang lain.
Tidak ada kondisi pada jalur keluar. Ini berbeda dari Exclusive dan Inclusive Gateway — Parallel Gateway tidak punya condition expression. Semua jalur selalu aktif.
Parallel Join (Converging / Penggabungan)
Ketika token dari berbagai jalur tiba di Parallel Join, gateway menunggu semua token sebelum melanjutkan. Begitu semua jalur selesai, satu token baru diteruskan.
[Siapkan Kontrak] ──┐
[Setup Akun] ──┤
◇+──→ [Sambut Karyawan]
[Konfigurasi Email]─┤
[Assign Mentor] ──┘
Gateway tidak akan melanjutkan sampai keempat task selesai — bahkan jika tiga sudah selesai, gateway tetap menunggu yang keempat.
Aturan Penamaan Parallel Gateway
Berbeda dari Exclusive dan Inclusive, Parallel Gateway umumnya tidak diberi label — karena tidak ada keputusan yang perlu dijelaskan. Semua jalur selalu aktif.
Namun jika perlu memberi konteks, gunakan format deskripsi singkat:
| Konteks | Label yang Tepat |
|---|---|
| Split memulai fase paralel | Mulai Proses Paralel atau kosong |
| Join mengakhiri fase paralel | Semua Selesai atau kosong |
| Dalam diagram yang kompleks | Fork: Verifikasi / Join: Verifikasi |
Prinsipnya: Label pada Parallel Gateway bersifat opsional dan bertujuan membantu keterbacaan, bukan menjelaskan kondisi (karena tidak ada kondisi).
Label Sequence Flow Keluar
Karena tidak ada kondisi, label pada sequence flow keluar bersifat deskriptif (menjelaskan apa yang terjadi di jalur itu), bukan kondisional:
◇+ → "Proses Legal" → [Task Legal...]
◇+ → "Proses Finance" → [Task Finance...]
◇+ → "Proses IT" → [Task IT...]
Tidak perlu menulis kondisi seperti "jika A maka..." — cukup nama jalur atau nama departemen yang terlibat.
Kapan Menggunakan Parallel Gateway
Gunakan Parallel Gateway ketika:
✅ Beberapa pekerjaan bisa dan harus dilakukan secara bersamaan
✅ Pekerjaan tidak saling bergantung (tidak perlu menunggu satu selesai untuk memulai yang lain)
✅ Ingin mempersingkat total waktu proses (throughput time)
✅ Semua jalur selalu aktif — tidak ada kondisi yang menentukan jalur mana
Jangan gunakan ketika:
❌ Ada kondisi yang menentukan jalur mana yang aktif → pakai Inclusive atau Exclusive Gateway
❌ Hanya satu jalur yang perlu dieksekusi → tidak perlu gateway paralel
❌ Urutan antar task penting (task B harus selesai sebelum task C dimulai) → pakai Sequence Flow biasa, bukan parallel
Manfaat Konkret: Waktu Proses
Parallel Gateway adalah alat utama untuk mereduksi cycle time proses:
Tanpa Parallel Gateway (Sequential):
[Siapkan Kontrak: 2 hari] → [Setup Sistem: 1 hari] → [Training: 3 hari] → [Mulai Kerja]
Total: 6 hari
Dengan Parallel Gateway:
◇+ → [Siapkan Kontrak: 2 hari] ──┐
→ [Setup Sistem: 1 hari] ──┤◇+ → [Mulai Kerja]
→ [Training: 3 hari] ──┘
Total: 3 hari (dibatasi oleh task terpanjang)
Penghematan: 3 hari (50%) hanya dengan mengidentifikasi bahwa ketiga task bisa dilakukan bersamaan.
Deadlock: Risiko Utama Parallel Gateway
Deadlock adalah kondisi di mana proses berhenti selamanya karena Parallel Join menunggu token yang tidak akan pernah datang.
Penyebab Deadlock yang Paling Umum
Penyebab 1: Jalur bercabang sebelum Join
❌ BERMASALAH:
→ [Task A] ──────────────────────────────────────┐
◇+ Split ◇+ Join
→ [Task B] → [Gateway X: "Kondisi?"] │
├─ "Ya" → [Task C] ──────────┘
└─ "Tidak" → [End Event] ← Token hilang di sini!
Jika kondisi "Tidak", token dari jalur B berakhir di End Event. Parallel Join hanya menerima token dari Task A dan Task C ("Ya"). Ia akan menunggu token ketiga yang tidak akan pernah datang. Proses stuck selamanya.
Solusi: Pastikan semua jalur yang dimulai dari Parallel Split selalu berakhir di Parallel Join yang sama — tidak ada jalur yang "menghilang" sebelum Join.
Penyebab 2: Campuran Gateway yang Salah
❌ SALAH:
◇+ Parallel Split → [Task A], [Task B]
◇X Exclusive Join ← [Task A], [Task B]
Exclusive Join tidak menunggu — ia langsung melanjutkan saat token pertama tiba. Token kedua (dari jalur lain) kemudian tiba di gateway yang sudah "selesai" dan tidak tahu ke mana harus pergi. Bergantung pada engine, ini bisa menyebabkan duplicate execution atau token yang hilang.
Pola Parallel Gateway yang Umum
Pola 1: Fork-Join Sederhana
◇+ → [A] ──┐
→ [B] ──┤◇+
→ [C] ──┘
Paling dasar. Semua task berjalan paralel, semua harus selesai.
Pola 2: Nested Parallel (Fork dalam Fork)
◇+ → [A]
→ ◇+ → [B1] ──┐
→ [B2] ──┤◇+ → (lanjut ke join utama)
→ [C]
Beberapa jalur memiliki sub-paralel di dalamnya. Hati-hati dengan join yang benar.
Pola 3: Parallel dengan Waktu yang Berbeda-beda
◇+ → [Task Cepat: 1 jam] ──┐
→ [Task Sedang: 4 jam] ──┤◇+ → [Lanjutkan]
→ [Task Lambat: 2 hari] ──┘
Join menunggu task terlama (2 hari). Desain ini valid — pastikan task yang cepat tidak "membuang waktu" menunggu.
Pola 4: Parallel dengan Error Handling
◎ Error Boundary "Gagal"
↓
[Task A] ─────[Tangani Error A]
↑
◇+ Split
↑
[Task B] ─────[Tangani Error B]
↑
◎ Error Boundary "Gagal"
Setiap jalur paralel memiliki penanganan error sendiri.
Kesalahan Lain yang Umum
Menggunakan Parallel untuk Kondisi
❌ SALAH:
◇+ → [Task A: "jika kondisi X"]
→ [Task B: "jika kondisi Y"]
Parallel Gateway tidak bisa memiliki kondisi. Kondisi pada label hanya dekoratif — tidak dievaluasi. Kedua task akan selalu dieksekusi.
Solusi: Gunakan Inclusive Gateway jika ada kondisi.
Lupa Menutup dengan Parallel Join
❌ SALAH:
◇+ → [Task A] → [End Event]
→ [Task B] → [End Event]
Kedua jalur berakhir di End Event masing-masing. Ini valid secara BPMN, tapi artinya proses selesai dua kali secara independen — yang mungkin bukan yang dimaksud.
Contoh Lengkap: Onboarding Karyawan Baru
[Start: Karyawan Diterima]
↓
◇+ "Mulai Persiapan Paralel"
├─→ Lane IT: [Service Task: Buat Akun Email Kantor]
│ [Service Task: Setup Laptop & Akses VPN]
│ [Service Task: Grant Akses Sistem Sesuai Posisi]
│
├─→ Lane HRD: [User Task: Siapkan Kontrak & Dokumen]
│ [User Task: Daftarkan ke BPJS & Asuransi]
│
└─→ Lane Manager: [User Task: Buat Rencana 30-60-90 Hari]
[User Task: Jadwalkan 1-on-1 Pertama]
↓ (semua selesai)
◇+ "Semua Persiapan Selesai"
↓
[User Task: Orientasi Hari Pertama]
↓
[End]
Selanjutnya: Event-Based Gateway →