BPMN 2.0 Lengkap
17 October 2026 • 17 menit baca • Belajar BPMN, BPMN 2.0 Tutorial, BPMN Diagram, BPMN Gateway, BPMN approval workflow, BPMN Swimlane, BPMN Subprocess, BPMN Event, BPMN Tools, bpmn-js, Workflow Modeling, Business Process Modeling. BPMN 2.0
BPMN 2.0 Lengkap: Memahami Swimlane, Subprocess, Gateway, Event, dan Tools untuk Enterprise System
Dalam pengembangan aplikasi enterprise, memahami proses bisnis sama pentingnya dengan memahami teknologi yang digunakan untuk membangun sistem. Sebuah aplikasi procurement, insurance, finance, atau human resource management tidak cukup hanya memiliki fitur CRUD. Sistem tersebut juga perlu menjalankan urutan aktivitas, mengatur kewenangan, memproses keputusan bisnis, menangani pengecualian, dan memastikan setiap transaksi memiliki status yang konsisten.
Di sinilah Business Process Model and Notation (BPMN) memiliki peran penting.
BPMN merupakan standar notasi untuk memodelkan proses bisnis melalui elemen visual yang terstruktur. Dengan BPMN, Business Analyst, System Analyst, Product Owner, developer, dan stakeholder bisnis dapat membahas proses menggunakan representasi yang sama.
Namun, mempelajari BPMN tidak cukup hanya dengan menghafal simbol. Kita juga perlu memahami kapan menggunakan swimlane, kapan sebuah proses sebaiknya dipisahkan menjadi subprocess, bagaimana gateway menentukan jalur proses, serta bagaimana event memengaruhi perjalanan suatu transaksi.
Artikel ini membahas BPMN 2.0 secara menyeluruh, mulai dari konsep dasar, penggunaan elemen, contoh kasus enterprise, hingga tools yang dapat digunakan untuk membuat, menampilkan, mengembangkan, dan menguji diagram BPMN.
1. Apa Itu BPMN 2.0?
BPMN adalah singkatan dari Business Process Model and Notation. Standar ini dikembangkan untuk menyediakan notasi proses bisnis yang dapat dipahami oleh berbagai pihak, mulai dari pengguna bisnis hingga tim teknis yang bertanggung jawab atas implementasi sistem.
Dokumentasi resmi standar dapat ditemukan di BPMN.org, yang dikelola dalam ekosistem Object Management Group (OMG).
BPMN 2.0 tidak hanya mendefinisikan tampilan simbol pada diagram. Standar ini juga memiliki model semantik dan format pertukaran berbasis XML sehingga diagram dapat direpresentasikan sebagai model terstruktur dan diproses oleh perangkat lunak yang kompatibel.
Dalam praktiknya, BPMN dapat digunakan untuk tiga kebutuhan utama.
| Kebutuhan | Tujuan | Contoh |
|---|---|---|
| Business Process Modeling | Memahami dan mendokumentasikan proses bisnis | Proses pengajuan pembelian |
| System Analysis and Design | Menurunkan proses menjadi kebutuhan aplikasi | Menentukan status transaksi dan aturan approval |
| Executable Process Modeling | Mendefinisikan proses yang dapat dijalankan oleh workflow engine yang mendukung BPMN | Approval klaim asuransi yang melibatkan human task dan service task |
Penting dipahami bahwa diagram BPMN tidak otomatis menjadi aplikasi. Untuk mengeksekusi proses, sistem tetap membutuhkan engine yang sesuai, implementasi aktivitas, integrasi, penyimpanan data, serta kontrol akses.
2. Mengenal Komponen Utama BPMN
BPMN memiliki sejumlah kelompok elemen. Untuk mempelajarinya secara efektif, mulailah dari empat kelompok utama berikut.
| Kelompok | Elemen | Fungsi |
|---|---|---|
| Flow Objects | Event | Menandai awal, kejadian selama proses, atau akhir proses |
| Flow Objects | Activity | Menunjukkan pekerjaan yang dilakukan |
| Flow Objects | Gateway | Mengatur percabangan atau penggabungan alur |
| Connecting Objects | Sequence Flow | Menunjukkan urutan alur dalam proses |
| Connecting Objects | Message Flow | Menunjukkan komunikasi antarpeserta proses |
| Swimlanes | Pool dan Lane | Menunjukkan peserta dan pembagian tanggung jawab |
| Artifacts | Data Object, Group, Text Annotation | Memberikan konteks tambahan terhadap proses |
Keempat kelompok tersebut membentuk dasar pemodelan. Setelah memahami fungsi masing-masing, kita dapat menggabungkannya menjadi proses bisnis yang lebih kompleks.
3. Swimlane BPMN: Membagi Tanggung Jawab dalam Proses Bisnis
3.1. Apa itu swimlane?
Swimlane merupakan pendekatan untuk membagi diagram proses berdasarkan peserta atau tanggung jawab. Dalam BPMN, struktur ini menggunakan dua elemen utama, yaitu Pool dan Lane.
Pool mewakili satu participant dalam proses kolaborasi. Participant dapat berupa perusahaan, organisasi, pelanggan, vendor, atau sistem eksternal.
Lane merupakan pembagian di dalam sebuah pool untuk mengorganisasi aktivitas berdasarkan peran, divisi, fungsi, atau tanggung jawab tertentu.
Contohnya, proses procurement dapat menggunakan satu pool bernama Perusahaan, yang dibagi menjadi beberapa lane:
- Requester
- Procurement
- Budget Owner
- Warehouse
- Finance
Dengan pembagian tersebut, pembaca dapat mengetahui bukan hanya aktivitas apa yang berlangsung, tetapi juga siapa yang bertanggung jawab atas aktivitas tersebut.
3.2. Perbedaan Pool dan Lane
| Aspek | Pool | Lane |
|---|---|---|
| Fungsi | Mewakili participant | Membagi tanggung jawab dalam participant |
| Contoh | Perusahaan, Vendor, Nasabah | Procurement, Finance, Claims Analyst |
| Hubungan proses | Komunikasi antarpool dapat menggunakan Message Flow | Sequence Flow dapat berpindah antarlane dalam pool yang sama |
| Penggunaan | Memodelkan kolaborasi antarorganisasi atau participant | Memperjelas pembagian pekerjaan |
| Independensi | Dapat memiliki proses sendiri atau menampilkan participant sebagai black-box pool | Bukan participant terpisah hanya karena berada pada lane berbeda |
Perbedaan ini penting karena penggunaan garis penghubung yang salah dapat membuat diagram BPMN ambigu atau tidak sesuai notasi standar.
3.3. Contoh penggunaan swimlane pada procurement
Misalnya, perusahaan ingin memodelkan proses pengadaan barang.
| Lane | Aktivitas |
|---|---|
| Requester | Mengajukan kebutuhan barang atau jasa |
| Procurement | Memvalidasi permintaan dan memilih vendor |
| Budget Owner | Memeriksa anggaran dan memberikan persetujuan |
| Warehouse | Memverifikasi penerimaan barang |
| Finance | Memvalidasi invoice dan memproses pembayaran |
Jika permintaan tidak lengkap, proses dapat kembali kepada Requester untuk direvisi. Jika permintaan valid tetapi membutuhkan persetujuan, proses dilanjutkan kepada Budget Owner. Setelah barang diterima dan dokumen yang relevan sesuai, Finance dapat memproses kewajiban pembayaran.
Swimlane membantu menemukan aktivitas yang tidak memiliki pemilik, duplikasi pekerjaan, perpindahan tanggung jawab yang tidak jelas, dan titik persetujuan yang berpotensi memperlambat proses.
3.4. Kapan menggunakan beberapa pool?
Gunakan beberapa pool ketika diagram perlu menggambarkan interaksi antara participant yang berbeda.
Contohnya adalah proses pengadaan antara Perusahaan dan Vendor.
| Participant | Contoh aktivitas |
|---|---|
| Perusahaan | Menyetujui pembelian dan mengirim Purchase Order |
| Vendor | Menerima Purchase Order dan mengonfirmasi pesanan |
| Perusahaan | Menerima barang dan memvalidasi invoice |
| Vendor | Mengirim barang dan tagihan sesuai proses yang disepakati |
Sequence Flow mengatur urutan aktivitas di dalam proses masing-masing participant. Message Flow menunjukkan komunikasi antara Perusahaan dan Vendor, seperti pengiriman Purchase Order atau invoice.
Tidak setiap divisi perlu dijadikan pool terpisah. Jika Procurement dan Finance merupakan lane dalam proses internal perusahaan yang sama, penggunaan satu pool dengan beberapa lane biasanya lebih tepat.
4. BPMN Subprocess: Kapan Proses Perlu Dipecah Menjadi Subprocess?
4.1. Apa itu subprocess?
Subprocess adalah activity yang merepresentasikan sekumpulan aktivitas lain yang membentuk satu bagian dari proses yang lebih besar.
Tujuannya adalah mengelola kompleksitas. Alih-alih menampilkan puluhan aktivitas dalam satu diagram, proses utama dapat menampilkan aktivitas tingkat tinggi, sementara detail pekerjaan dijelaskan pada diagram subprocess.
Contohnya, proses utama klaim asuransi dapat menampilkan aktivitas Evaluasi Klaim. Aktivitas tersebut kemudian diperinci menjadi subprocess yang mencakup pemeriksaan polis, validasi dokumen, penilaian kerugian, investigasi jika diperlukan, dan penyusunan rekomendasi keputusan.
Subprocess bukan hanya cara merapikan diagram. Penggunaan yang tepat membantu menetapkan batas proses, tanggung jawab, kebutuhan data, serta titik integrasi.
4.2. Jenis subprocess dan aktivitas terkait
| Jenis | Pengertian | Kapan digunakan | Contoh kasus |
|---|---|---|---|
| Embedded Subprocess | Subprocess yang didefinisikan di dalam proses induknya | Ketika sekumpulan aktivitas merupakan bagian dari proses induk dan tidak perlu diperlakukan sebagai proses global yang dapat dipanggil terpisah | Validasi dokumen sebagai bagian dari klaim |
| Collapsed Subprocess | Cara menampilkan subprocess secara ringkas di diagram induk | Ketika detail proses ingin disembunyikan dari tampilan utama agar diagram lebih mudah dibaca | Diagram utama hanya menampilkan “Evaluasi Klaim” |
| Expanded Subprocess | Cara menampilkan isi subprocess secara langsung di dalam batas activity-nya | Ketika pembaca perlu melihat detail aktivitas pada diagram yang sama | Menunjukkan pemeriksaan dokumen dan gateway kelengkapan |
| Event Subprocess | Subprocess yang dimulai oleh event tertentu di dalam cakupan proses yang relevan, bukan melalui alur Sequence Flow normal menuju aktivitas tersebut | Ketika kejadian khusus perlu ditangani selama proses induk berlangsung | Menangani pembatalan atau pesan pembatalan yang relevan selama proses aktif |
| Transaction Subprocess | Subprocess yang merepresentasikan kumpulan aktivitas transaksional dengan semantik transaksi BPMN | Ketika proses memerlukan pemodelan penyelesaian atau pembatalan transaksi sesuai semantik BPMN | Skenario transaksi multiaktivitas yang memerlukan jalur pembatalan terdefinisi |
| Ad Hoc Subprocess | Subprocess yang berisi aktivitas yang urutan atau pelaksanaannya tidak ditentukan sepenuhnya oleh Sequence Flow normal | Ketika pekerjaan bersifat fleksibel dan aktivitas dapat dilakukan sesuai kebutuhan dalam batas aturan proses | Penanganan kasus investigasi yang membutuhkan beberapa pemeriksaan |
| Call Activity | Activity yang memanggil proses atau global task yang didefinisikan secara terpisah | Ketika satu proses atau aktivitas global perlu digunakan kembali oleh beberapa proses | Proses verifikasi identitas yang dipakai oleh onboarding dan klaim |
Catatan: Collapsed dan Expanded Subprocess merupakan cara visual menampilkan subprocess, bukan dua jenis semantik proses yang berbeda. Call Activity juga bukan embedded subprocess: Call Activity merujuk pada elemen global yang didefinisikan terpisah.
4.3. Contoh kasus: Subprocess validasi dokumen klaim
Sebuah perusahaan asuransi menerima klaim dari nasabah. Proses utama tidak perlu menampilkan setiap pemeriksaan dokumen secara detail.
Pada tingkat proses utama, alurnya dapat didefinisikan sebagai berikut:
| Urutan | Aktivitas | Hasil |
|---|---|---|
| 1 | Terima laporan klaim | Klaim terdaftar |
| 2 | Validasi dokumen | Status kelengkapan dokumen |
| 3 | Evaluasi cakupan polis | Hasil pemeriksaan cakupan |
| 4 | Penilaian klaim | Rekomendasi keputusan |
| 5 | Persetujuan klaim | Klaim disetujui, ditolak, atau dikembalikan sesuai aturan |
Aktivitas Validasi Dokumen dapat dijadikan embedded subprocess dengan rincian:
| Urutan | Aktivitas di dalam subprocess | Tujuan |
|---|---|---|
| 1 | Periksa dokumen wajib | Memastikan seluruh dokumen yang diwajibkan tersedia |
| 2 | Validasi identitas dan referensi polis | Memastikan data terhubung dengan klaim yang benar |
| 3 | Periksa konsistensi data | Menemukan ketidaksesuaian informasi |
| 4 | Evaluasi kelengkapan | Menentukan apakah data cukup untuk melanjutkan |
| 5 | Kembalikan untuk dilengkapi atau selesaikan validasi | Menghasilkan status yang dapat digunakan proses induk |
Keuntungan pendekatan ini adalah proses utama tetap ringkas, sementara detail validasi dapat dianalisis dan diuji secara terpisah.
4.4. Kapan menggunakan Call Activity?
Misalnya, sebuah perusahaan memiliki proses verifikasi identitas yang digunakan oleh:
- Customer onboarding
- Pengajuan polis
- Pengajuan klaim
- Pembukaan akun mitra
Jika proses verifikasi tersebut didefinisikan sebagai proses global, setiap proses pemanggil dapat menggunakan Call Activity untuk merujuk kepadanya.
Pendekatan ini membantu mengurangi duplikasi definisi proses. Namun, desain tetap perlu menentukan bagaimana data masukan dan keluaran dipetakan, bagaimana kegagalan ditangani, serta bagaimana perubahan pada proses yang digunakan bersama berdampak pada proses pemanggil.
4.5. Kapan subprocess tidak diperlukan?
Tidak setiap rangkaian aktivitas perlu dipecah menjadi subprocess. Jika proses hanya memiliki beberapa aktivitas sederhana dan jalurnya mudah dipahami, satu diagram mungkin sudah cukup.
Subprocess mulai bermanfaat ketika:
- Diagram utama terlalu padat.
- Satu kelompok aktivitas memiliki tujuan bisnis yang jelas.
- Detail proses perlu dikelola secara terpisah.
- Sebuah proses perlu digunakan kembali melalui Call Activity.
- Tim membutuhkan batas yang lebih jelas untuk analisis, pengujian, atau tanggung jawab.
Subprocess yang terlalu banyak justru dapat membuat pembaca kesulitan mengikuti proses. Pilih tingkat detail berdasarkan kebutuhan pembaca dan kompleksitas proses, bukan sekadar jumlah aktivitas.
5. BPMN Event: Memodelkan Awal, Kejadian, dan Akhir Proses
Event menggambarkan sesuatu yang terjadi dan memengaruhi perjalanan proses. Event berbeda dari Task karena event tidak merepresentasikan pekerjaan yang dilakukan secara aktif oleh seseorang atau sistem.
5.1. Kategori event
| Kategori | Fungsi | Contoh |
|---|---|---|
| Start Event | Memulai sebuah proses atau subprocess | Permintaan pembelian diterima |
| Intermediate Event | Menangani kejadian saat proses sedang berlangsung | Menunggu respons vendor |
| End Event | Menandai akhir jalur proses | Permintaan selesai |
| Boundary Event | Ditempelkan pada batas activity atau subprocess untuk menangani kejadian terkait activity tersebut | Timer untuk batas waktu respons |
| Event Subprocess Start Event | Memicu event subprocess dalam cakupannya | Menerima pesan pembatalan yang relevan |
Event dapat dibedakan lagi berdasarkan trigger atau hasilnya, seperti Message, Timer, Error, Signal, Escalation, Conditional, dan Compensation. Ketersediaan dan arti event bergantung pada konteks penggunaannya.
5.2. Jenis event yang sering digunakan
| Event | Kegunaan | Contoh enterprise |
|---|---|---|
| Message Event | Menangani pesan yang dikirim atau diterima | Menerima konfirmasi vendor |
| Timer Event | Memicu atau menandai kondisi berbasis waktu | Eskalasi tugas yang melewati SLA |
| Error Event | Menangani error sesuai semantik BPMN | Kegagalan aktivitas pada subprocess yang memiliki jalur error |
| Conditional Event | Merespons kondisi yang terpenuhi | Melanjutkan proses ketika kondisi bisnis tertentu terpenuhi |
| Signal Event | Mengirim atau menerima sinyal yang dapat menjangkau proses yang relevan | Mengumumkan kejadian lintas proses |
| Escalation Event | Menangani eskalasi dalam konteks proses | Eskalasi kepada supervisor |
| Compensation Event | Memodelkan aktivitas kompensasi terhadap pekerjaan yang telah selesai | Membatalkan efek bisnis melalui aktivitas kompensasi yang dirancang |
Jangan menyamakan semua event dengan notifikasi. Message Event, misalnya, merepresentasikan pertukaran pesan dalam model proses; notifikasi email atau WhatsApp adalah salah satu kemungkinan implementasi teknisnya.
5.3. Interrupting dan non-interrupting boundary event
Boundary Event dapat memiliki perilaku interrupting atau non-interrupting, bergantung pada jenis event dan konfigurasi model.
| Perilaku | Arti | Contoh |
|---|---|---|
| Interrupting | Ketika event terjadi, jalur aktivitas yang relevan dihentikan dan proses mengikuti jalur event | Aktivitas pemeriksaan dihentikan ketika error yang ditangani terjadi |
| Non-interrupting | Event memicu jalur tambahan tanpa menghentikan aktivitas utama | Pengingat dikirim ketika tugas belum selesai, sementara tugas masih aktif |
Contoh penting adalah Timer Boundary Event pada tugas approval. Jika timer hanya memicu pengingat, aktivitas approval dapat tetap berjalan. Jika kebijakan perusahaan menyatakan proses harus dialihkan setelah batas waktu tertentu, desain event dan jalurnya harus sesuai dengan aturan tersebut.
Implementasi SLA juga membutuhkan definisi yang jelas mengenai kapan timer dimulai, apakah waktu dihitung berdasarkan hari kerja, bagaimana hari libur ditangani, dan apa yang terjadi setelah eskalasi.
6. BPMN Gateway: Mengendalikan Keputusan dan Alur Paralel
Gateway digunakan untuk mengatur percabangan atau penggabungan alur proses. Gateway bukan aktivitas bisnis itu sendiri, melainkan elemen pengendali alur.
| Gateway | Fungsi | Contoh |
|---|---|---|
| Exclusive Gateway (XOR) | Memilih satu jalur berdasarkan kondisi | Klaim disetujui atau ditolak |
| Parallel Gateway (AND) | Membagi atau menyatukan alur paralel | Pemeriksaan anggaran dan compliance berjalan bersamaan |
| Inclusive Gateway (OR) | Memungkinkan satu atau lebih jalur dipilih sesuai kondisi | Meminta satu atau beberapa jenis pemeriksaan tambahan |
| Event-Based Gateway | Menentukan jalur berdasarkan event yang terjadi lebih dahulu | Menunggu konfirmasi vendor atau timeout |
| Complex Gateway | Memodelkan aturan percabangan atau penggabungan yang lebih kompleks | Melanjutkan setelah kondisi gabungan tertentu terpenuhi |
Perbedaan penting: XOR memilih satu jalur, sedangkan OR dapat memilih beberapa jalur. AND digunakan untuk jalur paralel, sementara Event-Based Gateway menunggu kejadian yang menentukan jalur selanjutnya.
Dalam diagram enterprise, kondisi gateway harus ditulis secara jelas. Misalnya, "Nilai klaim di bawah batas kewenangan?" lebih mudah dianalisis daripada label "Valid?" yang tidak menjelaskan aturan pemeriksaan.
7. BPMN Task: Menentukan Jenis Aktivitas yang Tepat
Task merepresentasikan pekerjaan dalam proses. BPMN menyediakan beberapa jenis task yang dapat membantu menjelaskan karakter aktivitas.
| Jenis Task | Fungsi | Contoh penggunaan |
|---|---|---|
| User Task | Aktivitas yang diselesaikan melalui interaksi pengguna | Claims analyst meninjau klaim |
| Manual Task | Aktivitas yang dilakukan secara manual di luar kendali langsung aplikasi sebagai workflow activity | Pemeriksaan fisik barang |
| Service Task | Aktivitas yang dilakukan oleh layanan atau aplikasi | Mengambil data polis melalui API |
| Script Task | Aktivitas yang menjalankan skrip dalam lingkungan eksekusi yang mendukungnya | Transformasi data sederhana |
| Send Task | Mengirim pesan kepada participant atau penerima yang relevan | Mengirim permintaan konfirmasi |
| Receive Task | Menunggu atau menerima pesan | Menunggu konfirmasi vendor |
| Business Rule Task | Mengevaluasi aturan bisnis melalui mekanisme rule processing | Menentukan jalur approval dari matriks kewenangan |
Pemilihan jenis task harus sesuai dengan makna proses dan kemampuan workflow engine yang digunakan. Tidak semua engine mendukung seluruh fitur atau mengeksekusinya dengan cara yang sama.
8. Memahami Sequence Flow, Message Flow, dan Data Object
Selain event, task, dan gateway, hubungan antar elemen harus dimodelkan dengan benar.
| Elemen | Fungsi | Contoh |
|---|---|---|
| Sequence Flow | Menunjukkan urutan alur dalam satu proses | Validasi dilanjutkan ke approval |
| Message Flow | Menunjukkan komunikasi antarpeserta yang berbeda | Perusahaan mengirim PO kepada vendor |
| Association | Menghubungkan elemen dengan artefak atau informasi terkait tanpa mengatur urutan proses | Task dihubungkan dengan catatan atau data object |
| Data Object | Menunjukkan data yang digunakan atau dihasilkan aktivitas | Formulir pengajuan |
| Data Store | Menunjukkan tempat penyimpanan data yang relevan | Data transaksi pengadaan |
| Text Annotation | Memberikan keterangan tambahan | Catatan kebijakan approval |
Data Object dan Data Store memberikan konteks terhadap informasi yang digunakan proses. Namun, keduanya tidak menggantikan desain database, skema API, atau data ownership yang harus ditentukan dalam arsitektur aplikasi.
9. Tools BPMN: Memilih Alat Sesuai Kebutuhan
Tidak semua tools BPMN memiliki fungsi yang sama. Ada yang berfokus pada diagram, ada yang dapat ditanamkan ke dalam aplikasi, dan ada pula yang menyediakan runtime untuk menjalankan proses.
9.1. bpmn.io dan bpmn-js
bpmn.io menyediakan toolkit dan tools yang berkaitan dengan BPMN. Salah satu komponen utamanya adalah bpmn-js, yaitu library JavaScript untuk menampilkan dan memodelkan diagram BPMN 2.0 di browser.
Menurut dokumentasi bpmn-js, toolkit tersebut dapat digunakan sebagai viewer maupun modeler. Dokumentasi juga menjelaskan hubungan bpmn-js dengan diagram-js dan bpmn-moddle, yang mendukung interaksi diagram serta pembacaan dan penulisan model BPMN berbasis XML.
| Komponen atau contoh | Kegunaan | Kapan digunakan |
|---|---|---|
| Viewer | Menampilkan diagram BPMN | Menampilkan proses bisnis pada portal internal |
| NavigatedViewer | Menampilkan diagram dengan fasilitas navigasi | Membaca diagram yang berukuran besar |
| Modeler | Membuat dan mengedit diagram BPMN | Membangun editor proses dalam aplikasi |
| Properties Panel | Mengedit properti elemen yang didukung | Mengatur atribut task atau elemen model |
| Overlays | Menambahkan informasi di atas elemen diagram | Menampilkan status, catatan, atau metadata tambahan |
| Colors dan Theming | Menyesuaikan tampilan diagram | Membedakan kategori aktivitas atau status secara visual |
| Commenting | Menambahkan komentar pada diagram | Review proses bersama stakeholder |
| Diagram Diffing | Membandingkan dua versi diagram | Meninjau perubahan proses |
| Token Simulation | Memvisualisasikan pergerakan token untuk membantu memahami alur | Mengevaluasi logika jalur pada diagram |
| Custom Elements dan Modeling Rules | Memperluas elemen atau aturan pemodelan | Membangun modeler dengan kebutuhan khusus |
Daftar tersebut mengacu pada contoh yang tersedia di bpmn.io — bpmn-js Examples. Fitur pada halaman contoh tidak berarti seluruhnya tersedia sebagai fitur siap pakai dalam setiap instalasi. Sebagian merupakan demonstrasi ekstensi yang perlu diintegrasikan sesuai kebutuhan.
9.2. Bagaimana bpmn-js bekerja?
Secara konseptual, bpmn-js dapat dipahami melalui tiga lapisan.
| Lapisan | Peran |
|---|---|
| diagram-js | Menyediakan fondasi interaksi diagram, canvas, dan elemen grafis |
| bpmn-moddle | Membaca dan menulis struktur model BPMN 2.0 serta XML |
| bpmn-js | Menggabungkan keduanya dengan notasi, aturan pemodelan, dan interaksi khusus BPMN |
Pendekatan ini membuat bpmn-js cocok ketika perusahaan ingin mengintegrasikan BPMN ke dalam aplikasi web sendiri, misalnya portal dokumentasi proses, sistem desain workflow, atau aplikasi internal yang memerlukan viewer dan editor proses.
Namun, bpmn-js pada dasarnya adalah toolkit untuk diagram. Ia tidak dengan sendirinya menjadi workflow engine yang mengelola seluruh eksekusi proses bisnis.
9.3. Kapan menggunakan viewer dan kapan menggunakan modeler?
| Kebutuhan | Pilihan yang tepat |
|---|---|
| Pengguna hanya perlu membaca diagram | Viewer |
| Pengguna perlu memperbesar, menggeser, dan menelusuri diagram | NavigatedViewer |
| Business Analyst perlu membuat dan mengubah diagram | Modeler |
| Perusahaan ingin menyematkan editor BPMN ke aplikasi web | Modeler yang diintegrasikan ke aplikasi |
| Perusahaan ingin menjalankan proses dengan human task dan service task | Workflow engine yang mendukung kebutuhan eksekusi tersebut, bukan hanya bpmn-js |
Dokumentasi pengembangan tersedia melalui bpmn-js Walkthrough, termasuk contoh instalasi, penggunaan viewer, modeler, dan cara memperluas toolkit.
9.4. BPMN.org sebagai rujukan standar
BPMN.org merupakan portal resmi yang mengarahkan pembaca ke spesifikasi dan sumber pembelajaran BPMN dalam ekosistem OMG.
Gunakan sumber standar untuk memahami makna elemen dan aturan notasi. Gunakan dokumentasi tools untuk memahami cara membuat, menampilkan, mengedit, atau memperluas diagram.
Pemisahan ini penting: sebuah library dapat menyediakan cara menggambar elemen, tetapi arti dan perilaku elemen BPMN tetap harus mengacu pada standar dan kemampuan implementasi yang digunakan.
10. BPMN Diagramming Tool vs Workflow Engine
Salah satu kesalahpahaman yang sering terjadi adalah menganggap aplikasi untuk menggambar BPMN otomatis dapat mengeksekusi proses bisnis.
| Aspek | BPMN Diagramming Tool | Workflow Engine |
|---|---|---|
| Tujuan utama | Membuat, mengedit, atau menampilkan diagram | Menjalankan dan mengelola instance proses |
| Input utama | Model atau diagram BPMN | Definisi proses yang didukung oleh engine |
| Output utama | Diagram, model, atau file BPMN | Status proses, tugas, event, dan hasil eksekusi |
| Human task | Dapat dimodelkan sebagai simbol | Memerlukan runtime dan mekanisme tugas pengguna |
| Integrasi API | Bisa mendukung pengembangan integrasi aplikasi | Dapat menjalankan service task atau mekanisme integrasi yang sesuai |
| Monitoring runtime | Tidak otomatis tersedia hanya dari diagram | Bergantung pada kapabilitas engine dan solusi operasionalnya |
| Contoh penggunaan | Editor diagram pada portal perusahaan | Approval workflow yang berjalan dan menyimpan status transaksi |
Sebuah solusi dapat menggunakan bpmn-js untuk visualisasi dan editor, kemudian menghubungkan model BPMN dengan engine terpisah. Namun, hubungan tersebut memerlukan desain integrasi, validasi model, pengelolaan versi, serta kesesuaian antara elemen BPMN yang dimodelkan dan fitur yang didukung engine.
11. Contoh Penerapan BPMN pada Enterprise System
BPMN dapat diterapkan pada berbagai domain bisnis. Berikut contoh proses dan alasan pemodelannya.
| Domain | Contoh proses | Elemen BPMN yang relevan | Tujuan |
|---|---|---|---|
| Procurement | Purchase requisition hingga pembayaran | Swimlane, XOR Gateway, Subprocess, Message Flow | Memperjelas otorisasi, penerimaan barang, dan verifikasi invoice |
| Insurance | Registrasi hingga penyelesaian klaim | User Task, Service Task, Event, Subprocess | Memisahkan pemeriksaan dokumen, investigasi, keputusan, dan pembayaran |
| Finance | Invoice-to-payment | Gateway, Timer Event, Service Task, Boundary Event | Menangani validasi, approval, kegagalan pembayaran, dan rekonsiliasi |
| Human Resources | Employee onboarding | Call Activity, User Task, Message Event | Mengelola tugas lintas HR, IT, dan atasan |
| IT Service Management | Incident handling | Event, Gateway, Escalation, Subprocess | Mengatur prioritas, assignment, eskalasi, dan penyelesaian insiden |
| Customer Onboarding | Registrasi dan verifikasi identitas | Message Event, Service Task, Gateway | Mengatur validasi data dan pemeriksaan tambahan |
| Sales Operations | Lead-to-order | Swimlane, Gateway, Call Activity | Menghubungkan proses sales, approval harga, dan pemenuhan pesanan |
Elemen yang dipilih harus mengikuti kebutuhan proses. Tidak semua proses membutuhkan Event Subprocess atau Transaction Subprocess. Model yang baik menggunakan kompleksitas secukupnya untuk menggambarkan aturan bisnis dengan jelas.
12. Dari BPMN ke System Requirements
BPMN dapat menjadi sumber analisis untuk menyusun requirement, tetapi tidak menggantikan dokumen kebutuhan sistem.
Misalnya, dalam proses approval procurement, diagram menunjukkan bahwa permintaan harus melewati validasi dan persetujuan sebelum Purchase Order diterbitkan.
Dari alur tersebut, tim dapat menurunkan requirement berikut:
| Artefak | Contoh |
|---|---|
| Business Requirement | Pembelian harus mengikuti kewenangan dan kebijakan anggaran perusahaan |
| Functional Requirement | Sistem menentukan approver berdasarkan matriks kewenangan |
| User Story | Sebagai Budget Owner, saya ingin menerima permintaan pembelian yang menjadi tanggung jawab saya agar dapat meninjau dan memutuskan pengajuannya |
| Acceptance Criteria | Jika pengguna tidak memiliki kewenangan approval, sistem harus menolak tindakan persetujuan |
| Data Requirement | Sistem menyimpan identitas pengaju, nilai transaksi, status, approver, dan waktu keputusan |
| Integration Requirement | Purchase Order hanya diterbitkan setelah persetujuan yang diwajibkan selesai |
| Security Requirement | Hak akses dan segregasi tugas diterapkan pada tindakan pengajuan dan persetujuan |
Tahapan ini membuat hubungan antara proses bisnis, perilaku aplikasi, struktur data, dan pengujian menjadi lebih jelas.
13. Praktik Terbaik Saat Membuat BPMN
Untuk menghasilkan diagram yang dapat dipahami dan dipelihara, gunakan prinsip berikut.
1. Mulai dari tujuan bisnis.
Tentukan proses apa yang ingin dipahami atau diperbaiki sebelum memilih simbol.
2. Tentukan batas proses.
Jelaskan pemicu awal, hasil akhir, dan participant yang terlibat.
3. Gunakan swimlane sesuai tanggung jawab.
Hindari memisahkan setiap aktivitas ke lane tersendiri jika tidak memberikan informasi baru.
4. Gunakan subprocess untuk mengendalikan kompleksitas.
Pecah proses ketika sebuah kelompok aktivitas memiliki tujuan atau batas yang jelas.
5. Definisikan kondisi gateway secara eksplisit.
Hindari kondisi yang ambigu, seperti “sesuai?” tanpa menjelaskan kriteria yang digunakan.
6. Modelkan jalur pengecualian.
Perhatikan penolakan, revisi, timeout, error integrasi, dan proses kompensasi bila relevan.
7. Bedakan urutan aktivitas dan komunikasi.
Gunakan Sequence Flow dan Message Flow sesuai fungsi masing-masing.
8. Tentukan tingkat detail sesuai pembaca.
Diagram tingkat bisnis tidak perlu dipenuhi detail teknis API atau struktur database. Detail tersebut dapat diletakkan pada artefak desain sistem.
9. Validasi diagram dengan stakeholder.
Pastikan model sesuai dengan praktik aktual, kebijakan perusahaan, dan hasil yang diharapkan.
10. Jika BPMN akan dieksekusi, validasi terhadap engine.
Periksa dukungan terhadap task, event, gateway, subprocess, dan semantik lain yang digunakan.
Kesimpulan
BPMN 2.0 menyediakan cara yang terstruktur untuk memahami, mendokumentasikan, dan—dengan dukungan implementasi yang tepat—mengeksekusi proses bisnis. Swimlane membantu menjelaskan tanggung jawab, subprocess mengendalikan kompleksitas, gateway mengatur keputusan, dan event menangani kejadian yang memengaruhi jalannya proses.
Sementara itu, tools seperti bpmn-js menyediakan fondasi untuk menampilkan dan mengedit diagram BPMN dalam aplikasi web. Untuk menjalankan proses secara operasional, perusahaan perlu mempertimbangkan workflow engine, integrasi, data persistence, keamanan, dan monitoring.
Kunci penggunaan BPMN bukanlah menggunakan sebanyak mungkin simbol, melainkan memilih notasi yang tepat agar proses dapat dipahami oleh bisnis, diterjemahkan menjadi requirement yang terukur, dan diimplementasikan oleh tim teknologi.
Ethan Tech Digital membantu bisnis menganalisis proses, menyusun kebutuhan sistem, merancang arsitektur, dan mengembangkan solusi perangkat lunak yang disesuaikan dengan kebutuhan operasional perusahaan.
Pelajari solusi kami di https://ethantechdigital.com/ untuk mengenal pendekatan pengembangan sistem yang berfokus pada kebutuhan bisnis, integrasi, dan keberlanjutan teknologi.
Referensi resmi
- BPMN.org — portal standar dan dokumentasi BPMN: https://www.bpmn.org/
- bpmn.io — contoh penggunaan dan ekstensi bpmn-js: https://bpmn.io/toolkit/bpmn-js/examples/
- bpmn.io — panduan teknis bpmn-js: https://bpmn.io/toolkit/bpmn-js/walkthrough/
Butuh solusi digital untuk bisnis Anda?
Diskusikan Proyek →