BPMN vs Flowchart — Apa Bedanya?
Jawaban singkat: Flowchart adalah alat komunikasi visual serbaguna tanpa standar yang ketat. BPMN adalah bahasa pemodelan proses bisnis yang terstandar, mendukung kolaborasi antar pihak, dan — sejak versi 2.0 — bisa dieksekusi langsung oleh sistem. Keduanya menggambar alur, tapi untuk tujuan yang berbeda.
Jika flowchart adalah "peta kasar yang bisa dipahami siapa saja", maka BPMN adalah "blueprint arsitektur yang presisi dan bisa dibaca oleh mesin".
Mengapa Pertanyaan Ini Sering Muncul?
Secara visual, diagram BPMN dan flowchart memang terlihat mirip: keduanya menggunakan kotak, panah, dan belah ketupat. Kemiripan ini bukan kebetulan — BPMN memang terinspirasi dari gaya notasi flowchart.
Tapi persamaan visual itu berhenti di situ. Di balik tampilannya, BPMN dan flowchart memiliki fondasi, kemampuan, dan tujuan yang sangat berbeda.
Sekilas Sejarah: Dua Alat dari Dua Dunia Berbeda
Flowchart: Lahir dari Lantai Pabrik (1921)
Flowchart tidak lahir dari dunia komputer. Ia lahir dari dunia industrial engineering.
Pada 1921, pasangan Frank dan Lillian Gilbreth mempresentasikan "flow process chart" kepada American Society of Mechanical Engineers (ASME) dengan judul "Process Charts, First Steps in Finding the One Best Way to Do Work". Tujuannya: mendokumentasikan dan menganalisis gerakan pekerja di lantai pabrik untuk menemukan cara kerja yang paling efisien.
Flowchart kemudian diadopsi untuk dunia pemrograman komputer pada 1940-an oleh Herman Goldstine dan John von Neumann untuk merencanakan algoritma, lalu distandarisasi melalui ANSI X3.5 (1963/1970) dan ISO 5807:1985 — standar yang masih berlaku hingga hari ini.
Intinya: flowchart dirancang sebagai alat serbaguna untuk mendokumentasikan langkah-langkah dari hampir semua jenis proses — memasak, algoritma komputer, prosedur kerja, hingga resep kue.
BPMN: Lahir dari Frustrasi Dunia Bisnis (2001–2004)
BPMN lahir karena flowchart tidak cukup.
Pada akhir 1990-an dan awal 2000-an, perusahaan-perusahaan mulai menyadari bahwa mereka membutuhkan lebih dari sekadar "peta alur" — mereka membutuhkan bahasa standar yang bisa menjawab pertanyaan siapa yang bertanggung jawab, kejadian apa yang memicu proses, bagaimana dua organisasi berbeda berinteraksi, dan bagaimana diagram ini bisa langsung dijalankan oleh sistem.
Flowchart tidak bisa menjawab pertanyaan-pertanyaan itu.
BPMI (Business Process Management Initiative) dibentuk pada 2000 dengan misi menciptakan standar tersebut. Di bawah kepemimpinan Stephen A. White dari IBM, BPMN 1.0 dirilis pada 2004 — dan sejak 2005 dikelola oleh OMG (Object Management Group) yang juga memelihara UML.
Perbedaan Fundamental: Tabel Perbandingan
| Aspek | Flowchart | BPMN |
|---|---|---|
| Tujuan asal | Serbaguna — algoritma, prosedur, resep, apapun | Khusus proses bisnis |
| Standar simbol | ISO 5807 / ANSI X3.5 — ~19 simbol dasar, interpretasi bebas | OMG BPMN 2.0 — 100+ elemen, semantik ketat |
| Siapa melakukan apa | Tidak ada standar; harus dicantumkan manual | Built-in: Pool dan Lane mendefinisikan pelaku |
| Jenis kejadian (Event) | Tidak ada — hanya "Start" dan "End" oval | 30+ jenis Event: Timer, Message, Error, Signal, dll. |
| Kolaborasi antar pihak | Tidak tersedia secara standar | Built-in: Message Flow, Black Box Pool, Collaboration Diagram |
| Eksekusi oleh mesin | Tidak dirancang untuk ini | BPMN 2.0: bisa dieksekusi langsung oleh BPMS |
| Keputusan bercabang | Satu simbol diamond — tanpa membedakan jenis | Exclusive (XOR), Inclusive (OR), Parallel (AND), Event-Based |
| Penanganan eksepsi | Tidak ada standar | Boundary Event, Error Event, Compensation |
| Kompleksitas | Rendah — mudah dipelajari | Lebih tinggi — membutuhkan waktu untuk mahir |
| Audiensi | Siapa saja, termasuk non-teknis | Analis bisnis, developer, arsitek sistem |
| Tools umum | Visio, Draw.io, Miro, Lucidchart, kertas | Camunda Modeler, Signavio, bpmn.io, Bizagi |
Perbandingan Konkret: Proses yang Sama, Dua Cara Berbeda
Mari lihat kasus nyata: proses persetujuan pengajuan anggaran yang melibatkan staf, manajer, dan departemen keuangan.
Versi Flowchart
(Start)
↓
[Staf Membuat Pengajuan]
↓
[Kirim ke Manajer]
↓
◇ Disetujui Manajer?
├─→ Tidak → [Revisi] → (kembali ke awal)
└─→ Ya
↓
[Kirim ke Keuangan]
↓
◇ Dana Tersedia?
├─→ Tidak → [Tolak & Notifikasi]
└─→ Ya
↓
[Proses Anggaran]
↓
(End)
Flowchart ini dapat dibaca dan dipahami siapa saja. Tapi perhatikan apa yang tidak bisa dijawab dari diagram ini:
- Siapa yang mengerjakan langkah mana? (staf? manajer? sistem?)
- Berapa lama manajer punya waktu untuk menyetujui?
- Apa yang terjadi jika manajer tidak merespons dalam 3 hari?
- Apakah ada notifikasi email yang dikirim otomatis?
- Apakah manajer dan keuangan bisa mereview secara paralel?
- Di sistem mana pengajuan ini disimpan?
- Bisakah diagram ini langsung dijalankan oleh sistem BPM?
Semua pertanyaan itu tidak terjawab. Dan tidak ada cara standar untuk menjawabnya dalam flowchart.
Versi BPMN
┌──────────────────────────────────────────────────────────────────────────────┐
│ POOL: Perusahaan │
│ │
│ ┌────────────┬─────────────────────────────────────────────────────────────┐│
│ │ │ (●Start)──→[Buat Pengajuan Anggaran]──→(✉ Send: Kirim) ││
│ │ Staf │ ↓ ││
│ │ │ (✉ Catch: Terima Keputusan)←────────────┘ ││
│ ├────────────┼─────────────────────────────────────────────────────────────┤│
│ │ │ ↓ (✉ Catch: Terima Pengajuan) ││
│ │ │ (⏱ Timer: 3 hari)──[Eskalasi ke Direktur] ││
│ │ Manajer │ ↓ ││
│ │ │ [Review Pengajuan]──→◇ Keputusan? ││
│ │ │ "Setuju"↓ "Tolak"→[Kirim Penolakan]→(●)││
│ ├────────────┼─────────────────────────────────────────────────────────────┤│
│ │ │ ↓(✉ Receive: Pengajuan Disetujui) ││
│ │ Departemen │ [Cek Ketersediaan Dana]──→◇ Dana Tersedia? ││
│ │ Keuangan │ "Ya"↓ "Tidak"→[Notif Ditunda] ││
│ │ │ [Proses Anggaran]──→[Update Sistem]──→(●End) ││
│ └────────────┴─────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
Diagram BPMN ini menjawab semua pertanyaan yang tidak bisa dijawab flowchart:
- Siapa melakukan apa → Lane: Staf, Manajer, Departemen Keuangan
- Batas waktu → Timer Event: eskalasi otomatis setelah 3 hari tanpa respons
- Komunikasi antar peran → Message Events: pengajuan dikirim, keputusan diterima
- Jenis keputusan → Exclusive Gateway: hanya satu jalur yang diambil
- Eksekusi mesin → Diagram ini bisa langsung dijalankan di Camunda atau Flowable
Lima Hal yang Bisa BPMN Tapi Tidak Bisa Flowchart
1. Mendefinisikan Siapa yang Bertanggung Jawab
Flowchart tidak punya cara standar untuk menunjukkan pelaku. BPMN memiliki Pool (satu peserta/organisasi) dan Lane (peran/departemen di dalam organisasi) yang secara eksplisit menetapkan tanggung jawab setiap aktivitas.
Flowchart: [Verifikasi Dokumen]
(Siapa? Tidak jelas.)
BPMN: Lane "Petugas Loket" → [Verifikasi Dokumen]
(Jelas: Petugas Loket yang melakukan ini.)
2. Membedakan Jenis Kejadian (Event)
Flowchart hanya mengenal "Start" dan "End". BPMN memiliki lebih dari 30 jenis Event, masing-masing dengan makna yang berbeda:
| Event BPMN | Artinya | Padanan Flowchart |
|---|---|---|
| Timer Start Event | Proses dimulai setiap Senin pukul 08.00 | Tidak ada |
| Message Start Event | Proses dimulai saat menerima email | Tidak ada |
| Error End Event | Proses berakhir karena error | "End" — tanpa konteks |
| Escalation Boundary Event | Aktivitas diinterupsi karena eskalasi | Tidak ada |
| Compensation Event | Batalkan dan kompensasi aktivitas sebelumnya | Tidak ada |
3. Menggambarkan Kolaborasi Antar Organisasi
Flowchart tidak punya mekanisme standar untuk menggambarkan dua organisasi yang berbeda berinteraksi dalam satu diagram. BPMN memiliki Collaboration Diagram — beberapa Pool yang berkomunikasi melalui Message Flow:
┌──────────────────────┐
│ POOL: Nasabah │
│ [Ajukan KPR] ········│·········→ [Terima Pengajuan]
└──────────────────────┘ ┌─────────────────┐
│ POOL: Bank │
│ [Proses KPR] │
└─────────────────┘
4. Membedakan Jenis Percabangan (Gateway)
Flowchart hanya punya satu simbol diamond untuk semua jenis keputusan. BPMN membedakannya secara eksplisit:
| Gateway BPMN | Perilaku | Kapan Digunakan |
|---|---|---|
| Exclusive (XOR) | Hanya satu jalur yang dipilih | "Jika A maka X, jika B maka Y" |
| Parallel (AND) | Semua jalur berjalan serentak | "Kerjakan A dan B bersamaan" |
| Inclusive (OR) | Satu atau lebih jalur aktif | "Kerjakan A, dan mungkin juga B" |
| Event-Based | Jalur ditentukan oleh event yang datang duluan | "Tunggu respons atau timeout" |
Dalam flowchart, semua kasus di atas dilambangkan dengan diamond yang sama — tanpa perbedaan semantik.
5. Dapat Dieksekusi oleh Mesin
Ini perbedaan paling fundamental untuk konteks implementasi. BPMN 2.0 mendefinisikan format XML standar sehingga diagram dapat dibaca dan dieksekusi langsung oleh BPMS seperti Camunda, Flowable, atau IBM BPM.
Flowchart tidak pernah dirancang untuk ini. Tidak ada engine yang bisa "menjalankan" flowchart.
BPMN 2.0 XML (disederhanakan):
<process id="approvalProcess">
<startEvent id="start"/>
<userTask id="review" name="Review Pengajuan"/>
<exclusiveGateway id="decision"/>
<sequenceFlow sourceRef="review" targetRef="decision"
conditionExpression="${approved == true}"/>
</process>
→ Diagram ini LANGSUNG bisa dijalankan di Camunda atau Flowable.
Tidak perlu diterjemahkan ke kode lagi.
Lima Hal yang Flowchart Lebih Unggul dari BPMN
Perbandingan ini bukan tentang "mana yang lebih baik" — tapi tentang alat yang tepat untuk konteks yang tepat.
1. Lebih Mudah Dipelajari
Siapa pun bisa membuat flowchart dalam 15 menit. Tidak perlu pelatihan khusus, tidak perlu software mahal. BPMN membutuhkan pemahaman tentang semantik elemen, aturan penggunaan Pool/Lane, dan jenis Gateway yang benar.
2. Lebih Cocok untuk Algoritma dan Logika Program
Untuk menjelaskan logika if-else, loop, atau alur algoritma kepada developer, flowchart lebih natural dan langsung ke inti:
Contoh: Algoritma validasi email
(Start) → [Input Email] → ◇ Format @? → Tidak → [Error: Format Salah]
→ Ya → ◇ Domain Ada? → ...
Ini jauh lebih bersih daripada membungkusnya dalam Pool dan Lane BPMN yang tidak dibutuhkan.
3. Lebih Cepat untuk Brainstorming Awal
Saat eksplorasi ide proses di whiteboard atau sticky note, flowchart adalah medium yang tepat. Formalitas BPMN justru menghambat kecepatan berpikir di tahap ini.
4. Lebih Mudah Dipahami Audiensi Non-Teknis
Untuk presentasi kepada eksekutif atau pengguna non-teknis yang belum mengenal BPMN, flowchart sederhana lebih efektif. Tidak ada kurva pembelajaran.
5. Lebih Fleksibel untuk Dokumentasi Proses Sederhana
Untuk prosedur yang melibatkan satu pelaku, linear, dan tidak memerlukan otomasi, membuat diagram BPMN justru overkill. Flowchart satu halaman sudah lebih dari cukup.
Panduan: Kapan Pakai Flowchart, Kapan Pakai BPMN?
Gunakan Flowchart ketika:
✅ Proses melibatkan satu pelaku atau tanggung jawab sudah jelas dari konteks
✅ Proses bersifat linear dan sederhana — tidak banyak percabangan kompleks
✅ Tujuannya komunikasi cepat kepada audiensi yang beragam
✅ Anda mendokumentasikan algoritma atau logika program
✅ Ini adalah brainstorming awal sebelum detail ditentukan
✅ Tidak ada kebutuhan otomasi atau eksekusi oleh mesin
✅ Audiensi adalah non-teknis yang belum mengenal BPMN
Gunakan BPMN ketika:
✅ Proses melibatkan lebih dari satu peran, departemen, atau organisasi
✅ Anda perlu menunjukkan siapa bertanggung jawab atas setiap langkah
✅ Ada berbagai jenis kejadian (timer, pesan masuk, error, eskalasi)
✅ Proses akan diimplementasikan di BPMS (Camunda, Flowable, IBM BPM)
✅ Anda memodelkan kolaborasi antar perusahaan atau sistem
✅ Diagram digunakan sebagai spesifikasi teknis untuk development
✅ Proses perlu diaudit, disertifikasi, atau dikomunikasikan ke regulator
✅ Anda perlu membedakan jenis percabangan (parallel vs exclusive vs inclusive)
Tabel Keputusan Cepat
| Kondisi | Pilih |
|---|---|
| Lebih dari satu departemen terlibat | BPMN |
| Perlu tahu siapa yang melakukan apa | BPMN |
| Proses akan diotomasi dengan software BPM | BPMN |
| Ada timer atau batas waktu yang mempengaruhi alur | BPMN |
| Presentasi kepada eksekutif non-teknis | Flowchart |
| Menjelaskan algoritma kepada programmer | Flowchart |
| Brainstorming awal di whiteboard | Flowchart |
| Satu pelaku, proses linear sederhana | Flowchart |
| Dokumentasi proses untuk audit dan compliance | BPMN |
| Proses melibatkan dua perusahaan berbeda | BPMN |
Posisi BPMN dalam Keluarga Besar Notasi
Flowchart dan BPMN bukan satu-satunya pemain. Ada notasi lain yang perlu dipahami konteksnya:
| Notasi | Tujuan Utama | Hubungan dengan BPMN |
|---|---|---|
| Flowchart | Serbaguna: algoritma, prosedur, proses | Leluhur visual BPMN |
| BPMN | Proses bisnis: dokumentasi dan eksekusi | Standar utama untuk BPM |
| UML Activity Diagram | Alur kerja dalam desain perangkat lunak | Sepupu BPMN — berbagi akar flowchart tapi fokus untuk software design |
| EPC (Event-driven Process Chain) | Pemodelan proses SAP | Populer di Eropa, tapi digantikan BPMN |
| Value Stream Map | Analisis lean manufacturing | Lebih fokus pada waste, bukan alur kontrol |
Kesimpulan
Flowchart dan BPMN bukan pesaing — mereka adalah alat yang berbeda untuk pekerjaan yang berbeda.
Flowchart terbaik ketika Anda butuh komunikasi yang cepat, sederhana, dan universal. Ia lahir dari dunia pabrik pada 1921, dan selama seabad lebih terbukti efektif untuk mendokumentasikan logika yang mudah dipahami siapa saja.
BPMN terbaik ketika Anda butuh presisi, standarisasi, dan kemampuan eksekusi. Ia lahir dari frustrasi bahwa flowchart tidak cukup untuk mendokumentasikan proses bisnis yang kompleks, melibatkan banyak pihak, dan perlu diotomasi. BPMN adalah evolusi dari flowchart — mengambil kekuatan visualnya, lalu menambahkan lapisan semantik yang jauh lebih kaya.
Pertanyaannya bukan "mana yang lebih baik?" — tapi "apa yang benar-benar Anda butuhkan dari diagram ini?"
Selanjutnya: Notasi BPMN → — pelajari elemen-elemen yang membuat BPMN mampu mengekspresikan apa yang tidak bisa dilakukan flowchart.
Sudah memahami konsep BPMN?
Wujudkan diagram Anda menjadi *workflow automation* nyata tanpa *coding* — dengan **AlurKerja**, platform BPM buatan Indonesia.