Pool dan Lane
Pool dan Lane adalah fitur yang paling membedakan BPMN dari flowchart biasa. Dengan Pool dan Lane, diagram BPMN bisa menjawab pertanyaan "siapa yang bertanggung jawab atas setiap langkah" secara visual dan eksplisit — bukan hanya apa yang dilakukan, tapi oleh siapa.
Pool
Pool merepresentasikan satu peserta (participant) dalam sebuah proses kolaborasi. Peserta bisa berupa:
- Sebuah organisasi (Bank Mandiri, Kementerian Keuangan, PT Logistik Nusantara)
- Sebuah peran/entitas tunggal (Pelanggan, Supplier, Vendor)
- Sebuah sistem atau aplikasi (ERP System, Payment Gateway, Core Banking)
Bentuk: Persegi panjang besar yang membungkus semua elemen dalam proses peserta tersebut. Nama Pool biasanya ditampilkan secara vertikal di sisi kiri (orientasi horizontal).
Aturan Dasar Pool
| Aturan | Penjelasan |
|---|---|
| Sequence Flow tidak bisa melewati batas Pool | Alur eksekusi tetap di dalam Pool — ini bukan aturan gaya, ini aturan standar BPMN |
| Komunikasi antar Pool pakai Message Flow | Pesan, sinyal, atau data yang dikirim ke Pool lain menggunakan panah putus-putus |
| Setiap Pool punya proses sendiri | Masing-masing Pool adalah "dunia" yang berdiri sendiri |
Pool Biasa vs. Black Box Pool
| Jenis | Tampilan | Artinya |
|---|---|---|
| Pool Biasa | Berisi diagram proses yang terlihat | Kita tahu dan perlu memodelkan bagaimana peserta ini bekerja |
| Black Box Pool | Kotak kosong, hanya ada nama | Kita tahu peserta ini ada, tapi tidak perlu atau tidak bisa memodelkan prosesnya |
Kapan menggunakan Black Box Pool:
- Peserta eksternal yang prosesnya tidak kita kendalikan (Pelanggan, Bank Penerima, Regulator)
- Sistem pihak ketiga yang hanya diketahui input/output-nya (Payment Gateway, SMS Provider)
- Menjaga diagram tetap fokus pada proses internal yang kita kelola
Lane
Lane adalah subdivisi di dalam Pool yang mengelompokkan aktivitas berdasarkan siapa yang melakukannya — biasanya departemen, peran, atau sistem tertentu dalam satu organisasi.
Bentuk: Kolom atau baris di dalam Pool, dengan nama di sisi kiri (orientasi horizontal) atau atas (orientasi vertikal).
Prinsip Penggunaan Lane
- Setiap Task harus berada di dalam tepat satu Lane — ini mendefinisikan siapa yang bertanggung jawab
- Lane tidak menghalangi Sequence Flow — alur bisa melewati batas Lane dengan bebas
- Nama Lane sebaiknya menggunakan peran atau departemen, bukan nama orang
- Jika sebuah pekerjaan melibatkan dua peran, pecah menjadi dua Task yang masing-masing di Lane yang sesuai
Pilihan Nama Lane yang Baik
| Baik ✅ | Kurang Baik ❌ |
|---|---|
| Petugas Loket | Budi |
| Supervisor | Kepala Bagian Bu Sari |
| Sistem CRM | Aplikasi |
| Departemen Keuangan | Finance |
| Nasabah | Customer |
| Analis Kredit | Tim 1 |
| Payment Gateway | Server |
Orientasi: Horizontal vs. Vertikal
BPMN tidak mewajibkan orientasi tertentu, namun ada konvensi yang umum digunakan:
| Orientasi | Konvensi Umum | Kapan Digunakan |
|---|---|---|
| Horizontal (Lane = baris mendatar) | Lebih umum; alur berjalan kiri ke kanan | Mayoritas diagram proses bisnis |
| Vertikal (Lane = kolom tegak) | Swimlane bergaya spreadsheet | Proses dengan banyak Lane dan sedikit step |
Pilih satu orientasi dan konsisten dalam satu diagram.
Contoh 1: Proses Pengajuan Kredit (Satu Pool, Beberapa Lane)
Skenario: Nasabah mengajukan pinjaman ke bank. Proses internal bank melibatkan tiga departemen.
┌──────────────────────────────────────────────────────────────────────────────────┐
│ POOL: Bank │
│ │
│ ┌──────────────┬───────────────────────────────────────────────────────────────┐ │
│ │ │ [Start]──→[Terima Formulir]──→[Verifikasi Identitas]──→◇ │ │
│ │ Petugas │ │ │ │
│ │ Loket │ ←─────[Informasi Kekurangan]←──┘"Tdk" │ │
│ │ │ │ │
│ ├──────────────┼───────────────────────────────────────────────────────────────┤ │
│ │ │ "Ya"↓ │ │
│ │ Analis │ [Analisis Kelayakan]──→[Hitung Skor Kredit]──→◇ │ │
│ │ Kredit │ │ │ │
│ │ │ ←──[Susun Rekomendasi]←────┘ │ │
│ ├──────────────┼───────────────────────────────────────────────────────────────┤ │
│ │ │ [Rekomendasi Diterima]──→[Tanda Tangan Kontrak] │ │
│ │ Kepala │ ↑ ↓ │ │
│ │ Departemen │ [Review Rekomendasi] [Kirim Keputusan] │ │
│ │ │ ↑ ↓ │ │
│ ├──────────────┼───────────────────────────────────────────────────────────────┤ │
│ │ │ [Rekam ke Core Banking] [Cairkan Dana] │ │
│ │ Sistem │ ↑ ↓ │ │
│ │ Core │ (dari Analis) [Update Status Nasabah] │ │
│ │ Banking │ ↓[End] │ │
│ └──────────────┴───────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────┘
Yang bisa dibaca dari diagram ini:
- Petugas Loket bertugas di awal: menerima dan memverifikasi
- Analis Kredit melakukan penilaian kelayakan
- Kepala Departemen memberi persetujuan akhir
- Sistem Core Banking menangani pencatatan dan pencairan
Tanpa Lane, tidak ada cara untuk tahu siapa yang mengerjakan apa hanya dari diagram alur.
Contoh 2: Collaboration Diagram — Proses Pembelian Online (Beberapa Pool)
Skenario: Pelanggan memesan produk, Toko Online memproses, dan Payment Gateway mengotorisasi pembayaran.
┌──────────────────────────────────────────────────────────────────┐
│ POOL: Pelanggan (Black Box) │
│ │
│ [Pilih Produk]──→[Isi Data Pengiriman]──→[Lakukan Pembayaran] │
└──────────┬───────────────────────────────────────┬──────────────┘
│ Message Flow: "Data Pesanan" │ Message Flow: "Konfirmasi Pesanan"
↓ ↑
┌──────────────────────────────────────────────────────────────────┐
│ POOL: Toko Online │
│ ┌──────────────┬───────────────────────────────────────────────┐ │
│ │ Sistem │ [Terima Pesanan]──→[Validasi Stok]──→◇ │ │
│ │ Order │ "Ada" ↓ "Habis"→[Notif Habis]→[End] │
│ │ Management │ [Buat Invoice] │ │
│ ├──────────────┼───────────────────────────────────────────────┤ │
│ │ │ ↓ │ │
│ │ Sistem │ [Kirim Request Pembayaran] │ │
│ │ Pembayaran │ ↓ ↑ │ │
│ │ Internal │ [Tunggu Konfirmasi] [Proses Hasil] │ │
│ ├──────────────┼───────────────────────────────────────────────┤ │
│ │ Gudang │ [Siapkan Paket]──→[Serahkan ke Kurir]→[End] │
│ └──────────────┴───────────────────────────────────────────────┘ │
└──────────────────────────┬───────────────────────┬──────────────┘
│ Message Flow: │ Message Flow:
│ "Request Otorisasi" │ "Hasil Otorisasi"
↓ ↑
┌──────────────────────────────────────────────────────────────────┐
│ POOL: Payment Gateway (Black Box) │
└──────────────────────────────────────────────────────────────────┘
Yang dapat dipelajari dari contoh ini:
- Pelanggan adalah Black Box — kita tidak perlu memodelkan proses internal mereka
- Payment Gateway adalah Black Box — sistem pihak ketiga, kita hanya tahu apa yang dikirim dan diterima
- Toko Online punya proses internal lengkap dengan Lane per sistem/departemen
- Semua komunikasi antar Pool menggunakan Message Flow (panah putus-putus), bukan Sequence Flow
Contoh 3: Proses Onboarding Karyawan Baru (Pool dengan Lane Bertingkat)
Skenario: Rekrutmen karyawan baru melibatkan beberapa departemen dalam perusahaan.
┌─────────────────────────────────────────────────────────────────────────────────┐
│ POOL: Perusahaan │
│ │
│ ┌───────────────┬───────────────────────────────────────────────────────────┐ │
│ │ │ [Start: Terima Surat Penawaran] │ │
│ │ HRD │ ↓ │ │
│ │ Rekrutmen │ [Siapkan Dokumen Kontrak]──→[Kirim ke Karyawan Baru] │ │
│ │ │ ↓ (dokumen kembali) │ │
│ │ │ [Verifikasi Kelengkapan]────────────┘ │ │
│ ├───────────────┼───────────────────────────────────────────────────────────┤ │
│ │ │ ↓ │ │
│ │ IT │ [Buat Akun & Email]──→[Setup Perangkat]──→[Konfigurasi │ │
│ │ Support │ Akses Sistem] │ │
│ ├───────────────┼───────────────────────────────────────────────────────────┤ │
│ │ │ ↓ │ │
│ │ Manajer │ [Briefing Pertama]──→[Tetapkan Mentor]──→[Assign Proyek │ │
│ │ Departemen │ Onboarding] │ │
│ ├───────────────┼───────────────────────────────────────────────────────────┤ │
│ │ │ ↓ │ │
│ │ Keuangan │ [Input Data Payroll]──→[Setup Rekening Gaji]──→[End] │ │
│ └───────────────┴───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────┘
Keuntungan penggunaan Lane di sini:
- Setiap departemen tahu persis kapan giliran mereka dalam proses
- Handoff antar departemen terlihat jelas — di mana Sequence Flow melewati batas Lane
- Mudah mengidentifikasi bottleneck: jika proses sering macet di IT Support, itu terlihat dari diagram
Lane Bersarang (Nested Lane)
BPMN memungkinkan Lane di dalam Lane (nested lanes). Berguna untuk hierarki yang lebih dalam, misalnya departemen → sub-tim.
Pool: Departemen Kredit
├── Lane: Kepala Departemen
│ ├── Sub-Lane: Kepala Seksi Analisis
│ └── Sub-Lane: Kepala Seksi Persetujuan
└── Lane: Staf
├── Sub-Lane: Analis Kredit
└── Sub-Lane: Petugas Administrasi
Kapan menggunakan Nested Lane:
- Hierarki peran sangat relevan untuk proses (misalnya, eskalasi harus ke kepala seksi tertentu)
- Diagram sudah cukup besar sehingga pembaca membutuhkan konteks hierarki
Catatan: Gunakan nested Lane dengan hati-hati. Lebih dari dua level kedalaman akan membuat diagram sulit dibaca. Pertimbangkan memecah menjadi diagram terpisah.
Aturan Penting: Sequence Flow vs. Message Flow
Ini adalah kesalahan paling umum dalam BPMN pemula:
| Jenis Koneksi | Di mana? | Kapan? |
|---|---|---|
| Sequence Flow (→ panah solid) | Di dalam satu Pool | Menghubungkan elemen dalam proses yang sama |
| Message Flow (→ panah putus-putus) | Antar Pool | Mengirim atau menerima pesan antar peserta berbeda |
❌ SALAH — Sequence Flow melewati batas Pool:
┌─────────────────┐ ┌─────────────────┐
│ Pool: Nasabah │ │ Pool: Bank │
│ │ │ │
│ [Ajukan KPR] ──────────→ [Terima Formulir] │
│ │ │ │
└─────────────────┘ └─────────────────┘
(Sequence Flow tidak bisa melewati Pool — ini tidak valid dalam BPMN)
✅ BENAR — Message Flow untuk komunikasi antar Pool:
┌─────────────────────────┐ ┌────────────────────────────┐
│ Pool: Nasabah │ │ Pool: Bank │
│ │ │ │
│ [Ajukan KPR] │ │ [Terima Formulir Pengajuan]│
│ ↓ │ │ ↓ │
│ [End (Send: Formulir)] ·····→ [Start (Receive: Formulir)] │
│ │ │ │
└─────────────────────────┘ └────────────────────────────┘
(Message Flow — koneksi valid antar Pool)
Collaboration Diagram: Beberapa Pool Berinteraksi
Diagram yang menampilkan lebih dari satu Pool yang saling berinteraksi disebut Collaboration Diagram.
Kapan menggunakan:
- Memodelkan proses B2B (antara dua perusahaan berbeda)
- Menggambarkan integrasi sistem (sistem internal ↔ layanan eksternal)
- Proses layanan publik yang melibatkan lebih dari satu lembaga
Contoh: Proses Pengajuan Pinjaman (Collaboration)
┌───────────────────────────────────────────────────────────────────────────┐
│ POOL: Pemohon │
│ [Start]──→[Lengkapi Formulir]──→[Kirim ke Bank]──→(Tunggu)──→[End] │
│ ↓ Message ↑ Message │
└───────────────────────────────────────┼─────────────────────────┼─────────┘
↓ "Formulir Pengajuan" ↑ "Keputusan"
┌───────────────────────────────────────┼─────────────────────────┼─────────┐
│ POOL: Bank ↓ ↑ │
│ ┌───────────────┬──────────────────────────────────────────────────────┐ │
│ │ Petugas │ [Terima Formulir]──→[Cek Kelengkapan]──→[Input Data] │ │
│ ├───────────────┼──────────────────────────────────────────────────────┤ │
│ │ Analis │ [Analisis Risiko]──→[Beri Rekomendasi] │ │
│ ├───────────────┼──────────────────────────────────────────────────────┤ │
│ │ Komite │ [Rapat Persetujuan]──→◇ │ │
│ │ Kredit │ "Setuju"↓ "Tolak"→│ │
│ ├───────────────┼──────────────────────────────────────────────────────┤ │
│ │ Administrasi │ [Buat Surat Keputusan]──→[Kirim ke Pemohon]──→[End]│ │
│ └───────────────┴──────────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────────────────┘
Kesalahan Umum dan Solusinya
| Kesalahan | Penjelasan | Solusi |
|---|---|---|
| Sequence Flow melewati Pool | Tidak valid dalam standar BPMN 2.0 | Gunakan Message Flow + Intermediate Message Event |
| Task tidak dalam Lane manapun | Tidak jelas siapa yang bertanggung jawab | Masukkan semua Task ke dalam Lane |
| Lane terlalu umum ("Semua Departemen") | Tidak informatif, mengalahkan tujuan Lane | Spesifikkan peran yang tepat |
| Terlalu banyak Lane (>6) | Diagram menjadi sangat sempit dan sulit dibaca | Gabungkan Lane serupa, atau pecah jadi diagram terpisah |
| Nama Lane = nama orang | Tidak scalable ketika orang berganti jabatan | Gunakan nama peran atau jabatan |
| Message Flow di dalam satu Pool | Message Flow hanya untuk antar Pool | Gunakan Sequence Flow di dalam Pool |
| Pool kosong tanpa keterangan | Tidak jelas apakah ini Black Box yang disengaja | Beri label "Black Box" atau tambahkan Text Annotation |
Kapan Tidak Perlu Pool dan Lane?
Tidak semua diagram BPMN membutuhkan Pool dan Lane:
- Process Diagram sederhana untuk satu pelaksana: cukup tanpa Pool/Lane
- Sub-Process internal yang semua langkahnya dilakukan oleh satu peran
- Diagram untuk tujuan komunikasi cepat di mana tanggung jawab sudah jelas dari konteks
- Prototipe awal sebelum detail tanggung jawab ditentukan
Pool dan Lane paling berharga ketika ada ambiguitas tentang siapa yang melakukan apa — di situlah Lane menyelesaikan kebingungan, terutama dalam proses yang melibatkan handoff antar peran atau organisasi berbeda.
Ringkasan: Kapan Gunakan Apa
| Situasi | Solusi |
|---|---|
| Satu organisasi, satu pelaksana | Tidak perlu Pool/Lane |
| Satu organisasi, beberapa departemen | Satu Pool + beberapa Lane |
| Dua atau lebih organisasi berbeda | Collaboration Diagram (beberapa Pool) |
| Peserta eksternal yang prosesnya tidak diketahui | Black Box Pool |
| Hierarki dalam departemen yang perlu ditampilkan | Nested Lane |
Selanjutnya: Flow →
💡
Sudah memahami konsep BPMN?
Wujudkan diagram Anda menjadi *workflow automation* nyata tanpa *coding* — dengan **AlurKerja**, platform BPM buatan Indonesia.