Sub-Process vs. Call Activity

Ini adalah salah satu pertanyaan yang paling sering ditanyakan oleh praktisi BPMN:

"Kapan saya harus menggunakan Sub-Process, dan kapan Call Activity?"

Keduanya mengelompokkan sekumpulan aktivitas ke dalam satu unit yang bisa dikelola — tapi tujuan, perilaku, dan implikasinya sangat berbeda. Halaman ini membahas perbedaan secara mendalam dengan panduan keputusan yang praktis.

---

Perbandingan Langsung

Aspek	Sub-Process	Call Activity
Di mana definisinya?	Di dalam proses induk	Di luar, sebagai proses terpisah
Bisa dipanggil dari banyak proses?	❌	✅
Deployment terpisah?	❌ (satu file dengan induk)	✅ (file/deployment sendiri)
Berbagi variabel dengan induk?	✅ Otomatis	❌ Harus di-mapping eksplisit
Bisa versi sendiri?	❌	✅
Overhead	Sangat rendah	Lebih tinggi (child instance)
Cocok untuk	Struktur lokal, exception handling	Reuse, modularisasi
Monitoring	Bagian dari instance induk	Instance terpisah yang bisa dilacak

---

Kapan Memilih Sub-Process

1. Kelompok Aktivitas yang Hanya Ada di Satu Proses

Jika sekelompok aktivitas hanya relevan untuk satu proses dan tidak akan digunakan di tempat lain — gunakan Sub-Process.

Proses: Pengajuan Kredit
[Terima Berkas] → [Sub-Process: Verifikasi Berkas Kredit] → [Analisis]

Sub-Process: Verifikasi Berkas Kredit
  → Cek Kelengkapan Berkas
  → Legalisir Dokumen
  → Input ke Sistem

"Verifikasi Berkas Kredit" adalah proses yang sangat spesifik untuk pengajuan kredit — tidak akan dipakai di proses lain.

2. Penanganan Exception Kolektif

Ketika Anda ingin satu Boundary Event melindungi beberapa aktivitas sekaligus:

┌──────────────────────────────────────────────┐
│ Sub-Process: Integrasi dengan Sistem Eksternal│
│ [Panggil API A] → [Panggil API B] → [API C]  │
└──────────────────────────────────────────────┘
      ◎ Error Boundary "Koneksi Gagal"
            ↓
      [Aktifkan Mode Fallback]

Daripada pasang Error Boundary Event di tiga API Task secara terpisah — cukup satu di Sub-Process.

3. Menjaga Scope Variabel Tetap Bersih

Sub-Process bisa memiliki variabel lokal yang tidak terlihat dari proses induk. Berguna untuk menghindari "pencemaran" variabel proses.

Sub-Process: Hitung Skor
  Variabel lokal: skorMentah, faktorPenyesuaian, skorSementara
  Output ke induk: skorFinal (satu-satunya yang "keluar")

4. Proses yang Dideploy Bersama

Jika perubahan pada kelompok aktivitas ini selalu bersamaan dengan perubahan pada proses induk — Sub-Process adalah pilihan alami. Tidak ada overhead versioning terpisah.

5. Event Sub-Process

Ketika Anda butuh handler yang dipicu oleh event (bukan dari Sequence Flow), gunakan Event Sub-Process — ini tidak ada padanannya di Call Activity.

╔ ═ ═ Event Sub-Process: Tangani Pembatalan ═ ═ ╗
║ ◎ Message Start Event "Terima Pembatalan"      ║
║ [Batalkan Semua Reservasi] → [Proses Refund]   ║
╚ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ╝

---

Kapan Memilih Call Activity

1. Proses yang Digunakan di Banyak Tempat

Ini adalah alasan utama Call Activity ada. Jika sekelompok aktivitas sama akan muncul di lebih dari satu proses — buat sebagai proses global dan panggil via Call Activity.

Proses A: Pembukaan Rekening   → [Call: KYC] →
Proses B: Pengajuan Kredit     → [Call: KYC] →
Proses C: Upgrade Kartu Kredit → [Call: KYC] →
Proses D: Pembaruan Data       → [Call: KYC] →

2. Tim yang Berbeda Mengelola Proses yang Berbeda

Jika tim Compliance mengelola proses KYC, dan tim Retail mengelola proses pembukaan rekening — mereka bisa bekerja secara independen jika KYC adalah Call Activity (proses terpisah yang bisa dideploy sendiri).

3. Proses yang Membutuhkan Versioning Sendiri

Regulasi OJK mengubah prosedur KYC — dengan Call Activity, tim Compliance bisa update dan deploy versi baru KYC tanpa harus menyentuh proses pembukaan rekening, pengajuan kredit, dll.

Proses Pembukaan Rekening v1.0 → [Call: Proses KYC v1.0]
                              ↓ (regulasi berubah)
Proses Pembukaan Rekening v1.0 → [Call: Proses KYC v2.0]
(tidak perlu redeploy pembukaan rekening)

4. Monitoring yang Lebih Granular

Call Activity menghasilkan child process instance — Anda bisa memantau proses KYC secara terpisah di dashboard BPMS, melihat SLA-nya, berapa yang gagal, berapa yang slow.

5. Proses yang Kompleks dan Berdiri Sendiri

Jika "sekelompok aktivitas" tersebut sebenarnya sudah sangat kompleks — punya sub-process sendiri, banyak gateway, lane yang berbeda — lebih baik ia menjadi proses mandiri yang dipanggil via Call Activity.

---

Diagram Keputusan

Apakah sekelompok aktivitas ini akan digunakan
di lebih dari satu proses?
  │
  ├─ YA ──────────────────────────→ Call Activity
  │
  └─ TIDAK
       │
       Apakah tim berbeda yang mengelola?
       │
       ├─ YA ──────────────────────→ Call Activity
       │
       └─ TIDAK
            │
            Apakah butuh monitoring/versioning terpisah?
            │
            ├─ YA ──────────────────→ Call Activity
            │
            └─ TIDAK
                 │
                 Apakah dipicu oleh event (bukan sequence flow)?
                 │
                 ├─ YA ──────────────→ Event Sub-Process
                 │
                 └─ TIDAK
                      │
                      Apakah butuh exception handling kolektif?
                      │
                      ├─ YA ──────────→ Embedded Sub-Process
                      │
                      └─ TIDAK
                           │
                           Apakah hanya untuk struktur/keterbacaan?
                           │
                           ├─ YA ──────→ Embedded Sub-Process (collapsed)
                           │
                           └─ TIDAK
                                │
                                Task biasa mungkin sudah cukup

---

Analogi yang Mudah Diingat

Sub-Process = Prosedur internal di dalam dokumen SOP yang sama

"Lihat Lampiran B: Prosedur Verifikasi Berkas" — masih bagian dari dokumen SOP yang sama, tidak bisa dipakai terpisah

Call Activity = Dokumen SOP terpisah yang direferensikan

"Laksanakan sesuai SOP-KYC-001 versi terbaru" — dokumen SOP terpisah yang bisa diupdate sendiri dan direferensikan dari banyak SOP lain

---

Contoh Arsitektur: Sistem Perbankan

Bayangkan sebuah bank dengan 12 proses berbeda yang semua memiliki beberapa prosedur standar:

Proses-Proses:
├── Pembukaan Rekening
├── Pengajuan KPR
├── Pengajuan KKB
├── Pembuatan Kartu Kredit
├── Pinjaman Multiguna
└── ... (7 proses lainnya)

Proses Global (dipanggil via Call Activity):
├── KYC Standard          ← dipanggil oleh semua 12 proses
├── Verifikasi Pembayaran ← dipanggil oleh 8 proses
├── Approval 3-Level      ← dipanggil oleh 6 proses
├── Notifikasi Nasabah    ← dipanggil oleh semua 12 proses
└── Proses Pelaporan OJK  ← dipanggil oleh 4 proses

Setiap proses utama menggunakan Sub-Process untuk mengelola bagian yang unik:

Proses: Pengajuan KPR
[Start]
  → [User Task: Input Data]
  → [Call Activity: KYC Standard]          ← Global process
  → [Sub-Process: Penilaian Agunan KPR]    ← Spesifik KPR saja
      → [Appraisal Properti]
      → [Cek Sertifikat]
      → [Verifikasi NJOP]
  → [Call Activity: Approval 3-Level]      ← Global process
  → [Sub-Process: Pencairan KPR]           ← Spesifik KPR saja
      → [Akad Kredit]
      → [Notaris]
      → [Transfer ke Developer]
  → [Call Activity: Notifikasi Nasabah]    ← Global process
  → [End]

---

Dampak pada Organisasi

Dimensi	Sub-Process	Call Activity
Ownership	Satu tim (pemilik proses induk)	Bisa tim berbeda
Change Management	Perubahan dalam satu deployment	Perubahan independen
Testing	Test bersama proses induk	Test terpisah, mocking lebih mudah
Dokumentasi	Bagian dari satu diagram	Diagram mandiri yang terdokumentasi sendiri
Audit	Instance tunggal	Audit trail per child instance

---

Kembali ke: Gambaran Umum Activity →