User Task

User Task adalah task yang dikerjakan oleh manusia dengan bantuan sistem atau aplikasi. Ini adalah tipe task yang paling umum ditemukan dalam diagram BPMN — karena sebagian besar proses bisnis masih melibatkan manusia yang berinteraksi dengan sistem.

Simbol: Ikon siluet orang di sudut kiri atas persegi panjang sudut membulat

---

Definisi yang Tepat

User Task menjawab pertanyaan: "Siapa yang harus mengerjakan ini, dan melalui sistem apa?"

Kata kunci untuk mengenali User Task:

• Seorang karyawan mengisi formulir di aplikasi
• Seorang manajer menyetujui permintaan di sistem workflow
• Seorang analis mereview data di dashboard
• Seorang petugas memverifikasi dokumen di aplikasi

Perbedaan inti dengan tipe task lain:

• Bukan Manual Task — karena ada sistem yang membantu (formulir online, workflow engine, aplikasi)
• Bukan Service Task — karena ada manusia yang terlibat, bukan otomasi penuh

---

Komponen Konfigurasi User Task

Dalam implementasi di BPMS (Camunda, Flowable, Activiti), User Task memiliki properti berikut:

Assignee — Siapa yang Mengerjakan

Mendefinisikan siapa yang mendapat task ini. Ada beberapa cara:

Cara Assign	Contoh	Kapan Digunakan
User langsung	wisnu.manupraba	Task selalu dikerjakan orang tertentu
Group/Role	supervisor-kredit, tim-legal	Task bisa dikerjakan siapa saja dalam grup
Expression dinamis	${pemohon}	Ditentukan saat runtime berdasarkan data proses
Kosong (unassigned)	—	Task masuk ke pool, siapa yang ambil yang mengerjakan

Candidate Users & Candidate Groups

Berbeda dari Assignee tunggal, candidate berarti task bisa diklaim oleh siapa saja dari daftar atau grup tersebut — seperti antrian tiket di helpdesk.

Due Date — Batas Waktu

Menentukan kapan task harus selesai. Bisa berupa:

• Tanggal tetap: 2025-12-31
• Ekspresi dinamis: ${now() + duration('P2D')} (2 hari dari sekarang)
• Berguna untuk integrasi dengan fitur reminder dan eskalasi otomatis

Priority — Prioritas

Nilai numerik (0–100) yang menentukan urutan tampil di daftar task pengguna. Semakin tinggi angka, semakin prioritas.

Form — Antarmuka Pengguna

User Task biasanya terhubung dengan form yang diisi pengguna. Ada dua pendekatan:

Pendekatan	Keterangan
Embedded Form	Form didefinisikan langsung di BPMS
External Form	Form berada di aplikasi eksternal, BPMS hanya menyimpan data
Form Key	Referensi ke form di sistem lain

---

Pola Penggunaan yang Umum

Pola 1: Review dan Persetujuan

Pola paling klasik. Seorang atasan atau reviewer melihat informasi dan membuat keputusan.

• Ajukan Permintaan (Start) $\rightarrow$ Review oleh Supervisor (User Task) $\rightarrow$ Keputusan (Gateway) $\rightarrow$ Disetujui / Ditolak.

Properti khas:

• Form menampilkan data yang sudah diisi di step sebelumnya (read-only)
• Hanya field keputusan yang aktif (Setuju/Tolak + komentar)
• Due date biasanya 1–2 hari kerja

Pola 2: Input Data

Pengguna mengisi informasi baru yang belum ada sebelumnya.

• Start $\rightarrow$ Input Data Pelanggan (User Task, Assignee: petugas-pendaftaran) $\rightarrow$ Validasi Otomatis $\rightarrow$ ...

Pola 3: Klaim dari Antrian

Tidak ada assignee tetap — task diletakkan di "antrian" dan petugas yang tersedia mengambilnya.

• Masuk Antrian Helpdesk $\rightarrow$ Tangani Tiket (User Task, Candidate Group: tim-support, Assignee: dikosongkan).

Pola 4: Multi-Level Approval

User Task digunakan berantai untuk approval berjenjang.

• Staff Mengisi (User Task) $\rightarrow$ Supervisor Approve (User Task) $\rightarrow$ Manager Approve (User Task) $\rightarrow$ Direktur Approve (User Task).

---

Contoh Konteks Indonesia

Perbankan: Persetujuan Kredit

• Nama Task: Analisis Kelayakan Kredit
• Assignee: ${analisKredit}
• Due Date: P3D (3 hari)
• Form: Form analisis 5C (Character, Capacity, Capital, Collateral, Condition)
• Outcome Variable: hasilAnalisis (Layak / Tidak Layak / Perlu Review)

Pemerintahan: Validasi Berkas Perizinan

• Nama Task: Verifikasi Kelengkapan Berkas
• Candidate Group: petugas-fo
• Due Date: P1D (1 hari kerja)
• Form: Checklist berkas berdasarkan jenis perizinan
• Outcome Variable: berkasLengkap (true/false) + catatanKekurangan

Manufaktur: Quality Control

• Nama Task: Inspeksi Produk
• Candidate Group: tim-qc
• Form: Form checklist inspeksi dengan foto
• Outcome Variable: hasilInspeksi (Lulus / Gagal / Perlu Perbaikan)
• Priority: ${if(urgentOrder, 80, 50)}

---

Kesalahan Umum

1. Menggunakan User Task untuk Proses Otomatis

Jika tidak ada manusia yang terlibat, gunakan Service Task, bukan User Task. User Task yang tidak pernah ditampilkan ke pengguna adalah desain yang salah.

2. User Task Tanpa Form

User Task tanpa form membuat pelaksana tidak tahu apa yang harus dikerjakan. Selalu definisikan form atau minimal task description.

3. Assignee Nama Orang, Bukan Role

Jangan tulis assignee: budi.santoso untuk proses yang digunakan jangka panjang. Gunakan role/group agar proses tetap berjalan saat orang berganti.

4. Tidak Ada Due Date

User Task tanpa due date tidak bisa dipantau SLA-nya dan tidak memicu eskalasi otomatis. Selalu definisikan batas waktu.

---

User Task vs. Receive Task

Keduanya "menunggu input manusia" — tapi berbeda:

Aspek	User Task	Receive Task
Pengguna berinteraksi	Langsung di BPMS/form	Tidak harus — bisa via sistem lain
Mekanisme selesai	Pengguna submit form	Pesan diterima dari sistem
Contoh	"Approve di portal"	"Terima email konfirmasi dari vendor"

---

Selanjutnya: Manual Task →

---

Contoh Diagram BPMN Resmi

Berikut adalah contoh implementasi User Task dalam alur proses bisnis resmi (referensi dari Camunda):

Contoh 1: Proses Persiapan Makan Malam

Di bawah ini, "Suggest dish" adalah User Task (dikerjakan oleh manusia memilih menu di aplikasi), sedangkan "Prepare meal" adalah Manual Task (dikerjakan secara manual fisik).

Contoh 2: Proses Pemesanan Pizza

Di bawah ini, "Choose pizza" adalah User Task (pengguna memilih pizza di aplikasi), sedangkan "Order pizza" adalah Service Task (sistem mengirim pesanan otomatis ke restoran).