Pernah mengalami rapat yang terasa seperti sidang tanpa hakim? Semua orang hadir, semua orang bicara, tapi setelah dua jam, tidak ada yang benar-benar sepakat soal bagaimana sebuah proses seharusnya berjalan. Tim HR punya versi mereka sendiri. Tim IT punya asumsi yang berbeda. Manajemen melihat dari sudut pandang lain lagi. Dan ketika rapat selesai, masing-masing divisi kembali ke mejanya sambil membawa interpretasi yang berbeda-beda.

Ini bukan cerita fiksi. Ini terjadi di banyak perusahaan, hampir setiap hari.

Masalahnya bukan karena orangnya tidak kompeten. Masalahnya karena tidak ada satu gambar yang disepakati bersama tentang bagaimana sebuah proses seharusnya mengalir dari awal sampai akhir, dari siapa ke siapa. Dan di sinilah BPMN relevan. Bukan sebagai solusi ajaib, tapi sebagai bahasa bersama yang  kalau benar-benar dipakai bisa memangkas kebingungan itu secara signifikan.

Apa Sebenarnya BPMN Itu?

BPMN adalah singkatan dari Business Process Model and Notation. Mudahnya: standar notasi grafis yang dipakai untuk menggambarkan proses bisnis secara visual, dengan simbol-simbol yang maknanya sudah disepakati secara internasional. Awalnya dikembangkan oleh Business Process Management Initiative (BPMI), dan kini dikelola oleh Object Management Group (OMG) sebagai standar global.

Kenapa perlu standar? Karena tanpa standar, setiap orang menggambar flowchart dengan caranya sendiri. Satu perusahaan pakai kotak untuk keputusan, perusahaan lain pakai lingkaran. Satu analis pakai warna biru untuk proses manual, yang lain tidak pakai warna sama sekali. Hasilnya: diagram yang tidak bisa "dibaca" oleh orang dari luar tim pembuat.

Dalam BPMN, setiap simbol punya fungsi yang spesifik dan tidak bisa dipertukarkan sembarangan. Tabel berikut merangkum simbol-simbol dasar yang paling sering muncul dalam diagram BPMN:

Dengan kombinasi simbol-simbol itu, satu diagram BPMN bisa menggambarkan proses yang melibatkan puluhan langkah, banyak pihak, dan berbagai kondisi percabangan  semuanya dalam satu halaman yang bisa dibaca oleh orang teknis maupun non-teknis.

Perbedaan BPMN dengan flowchart biasa? Flowchart itu bebas interpretasi. BPMN punya aturan yang harus diikuti. Flowchart bisa cukup untuk menjelaskan alur sederhana, tapi begitu prosesnya melibatkan banyak departemen, banyak keputusan, dan interaksi antar sistem  BPMN jauh lebih presisi dan jauh lebih berguna.

Dalam praktiknya, BPMN dipakai untuk mendokumentasikan alur kerja yang sudah ada, menganalisis di mana letak kemacetan atau inefisiensi, merancang ulang proses yang sudah tidak relevan, sekaligus menjadi fondasi teknis untuk membangun sistem digital atau otomatisasi workflow. Kalau perusahaan serius soal efisiensi operasional, memahami gambar BPMN bukan sekadar pilihan  itu bagian dari cara kerja yang profesional.

Satu hal lagi yang perlu dipahami: BPMN bukan alat yang eksklusif untuk industri tertentu. Manufaktur, jasa keuangan, rumah sakit, logistik, e-commerce  semuanya bisa dan memang sudah menggunakannya. Selama ada proses yang berulang dan melibatkan lebih dari satu pihak, di situ BPMN bisa memberikan nilai nyata.

Baca juga : Notasi BPMN: Bahasa Universal untuk Pemetaan Proses Bisnis

Contoh BPMN 1: Alur Rekrutmen Karyawan 

Rekrutmen terlihat mudah dari luar. Buka lowongan, terima lamaran, wawancara, selesai. Kenyataannya? Tidak sesederhana itu.

Proses hiring melibatkan setidaknya tiga sampai empat pihak berbeda: divisi yang membutuhkan posisi, tim HR yang mengelola proses, manajer yang mewawancara, dan terkadang direksi yang harus menyetujui penawaran kerja. Kalau tidak ada peta yang jelas, mudah sekali terjadi momen seperti ini: kandidat menunggu satu minggu tanpa kabar karena tidak ada yang tahu siapa yang seharusnya menghubungi. Atau lebih parah, dua orang berbeda dari HR menghubungi kandidat yang sama dengan pesan yang kontradiktif.

Dalam diagram BPMN untuk alur rekrutmen, alurnya bisa terbagi dalam beberapa swimlane misalnya: Divisi Pengguna, HR, dan Manajer. Secara garis besar, prosesnya mengalir seperti ini:

Start Event → Divisi mengajukan kebutuhan posisi → HR menerima dan memvalidasi kebutuhan → Pembuatan job description → Publikasi lowongan → Seleksi administrasi berkas → Gateway: Lolos/Tidak

Dari gateway pertama ini, dua jalur terbuka. Kandidat yang tidak lolos administrasi langsung mendapat notifikasi penolakan, dan proses berakhir di sana. Kandidat yang lolos masuk ke tahap berikutnya: penjadwalan wawancara pertama bersama HR. Setelah wawancara HR, ada gateway lagi. Yang tidak lanjut, keluar. Yang lanjut, masuk ke wawancara dengan manajer atau user. Dari situ, ada satu gateway terakhir sebelum penawaran kerja diterbitkan dan setelah kandidat menyetujui, proses onboarding dimulai dan rangkaian rekrutmen resmi berakhir di End Event.

Yang membuat diagram BPMN ini sangat berguna bukan hanya visualnya, tapi karena setiap swimlane menunjukkan dengan jelas siapa bertanggung jawab atas langkah mana. Tidak ada lagi pertanyaan "ini harusnya HR yang tindak lanjut atau manajernya?" Semuanya sudah terpeta. Tim IT pun bisa menggunakan diagram ini sebagai spesifikasi teknis kalau perusahaan ingin membangun sistem rekrutmen digital  karena alurnya sudah didefinisikan dengan tepat, bukan berdasarkan asumsi.

Menariknya, proses rekrutmen jadi salah satu contoh BPMN yang paling sering dipakai sebagai bahan latihan bagi pemula  bukan karena simple, tapi karena cukup familiar sehingga validasinya mudah dilakukan tanpa harus jadi ahli operasional terlebih dahulu. Dan ketika diagram pertama berhasil dibuat dan divalidasi bersama tim, kepercayaan untuk memetakan proses lain yang lebih kompleks biasanya tumbuh dengan sendirinya.

Contoh BPMN 2: Pengadaan Barang (Procurement)

Kalau ada satu area operasional yang paling rentan terhadap miskomunikasi, procurement-lah salah satunya.

Bayangkan skenario yang sangat umum terjadi: user mengirim email permintaan barang ke manajernya. Manajer membalas "oke" tapi tidak ada tindak lanjut konkret karena email itu tenggelam di antara puluhan email lain. Seminggu kemudian, user follow up. Barulah manajer meneruskan ke tim purchasing. Tim purchasing menghubungi user lagi karena spesifikasi barangnya tidak jelas. Proses baru benar-benar berjalan dua minggu setelah permintaan pertama dikirim. Lalu ketika barang datang, invoice masuk ke finance  tapi finance tidak punya informasi apakah barang sudah benar-benar diterima atau belum.

Chaos yang sistematis. Dan ini sepenuhnya bisa dicegah dengan gambar BPMN yang tepat.

Alur procurement yang sudah dipetakan dengan notasi BPMN kurang lebih berjalan seperti ini:

Start Event → User membuat Purchase Request (PR) secara formal → Manajer menerima dan mereview → Gateway: Disetujui/Ditolak

Kalau ditolak, notifikasi dikirim ke user dan proses selesai. Kalau disetujui, PR diteruskan ke tim Purchasing. Dari sini alur berlanjut: pemilihan vendor berdasarkan daftar vendor yang sudah tersertifikasi → penerbitan Purchase Order (PO) → vendor menerima PO dan mengemas barang → pengiriman → proses receiving di gudang → Gateway: Barang Sesuai/Tidak

Kalau barang tidak sesuai spesifikasi atau jumlah, dilakukan proses retur ke vendor dan menunggu pengiriman ulang. Kalau sesuai, dokumen penerimaan barang dikirim ke finance → invoice diproses → pembayaran dilakukan → End Event.

Penelitian terhadap departemen Procurement di beberapa perusahaan manufaktur Indonesia — termasuk yang pernah didokumentasikan dalam konteks PT. Mayora Indah — menunjukkan bahwa absennya model proses yang baku adalah akar dari banyak masalah koordinasi antar bagian. Procurement bukan hanya soal beli-beli barang; itu rantai keputusan yang panjang, dan setiap mata rantai harus terhubung dengan jelas.

BPMN memberikan keterhubungan itu dalam satu lembar diagram.

Contoh BPMN 3: Persetujuan Dokumen Internal

Ada yang menganggap proses approval dokumen itu hal kecil. Sampai mereka mengalami sendiri: proposal anggaran yang sudah tiga minggu "di meja" seseorang tapi tidak ada kabar lanjutannya. Atau kontrak yang gagal ditandatangani tepat waktu karena tidak ada yang tahu bahwa dokumen itu menunggu persetujuan direksi.

Persoalannya bukan pada orangnya yang malas. Persoalannya adalah tidak ada visibilitas  tidak ada yang bisa melihat: dokumen ini sekarang ada di mana, tahap berapa, dan siapa yang seharusnya bertindak selanjutnya.

Dalam diagram BPMN untuk alur approval dokumen, swimlane biasanya mencakup: Pemohon (yang membuat dokumen), Supervisor, Manager, dan Direksi  dengan catatan bahwa eskalasi ke level tertentu bisa bergantung pada nilai atau jenis dokumennya.

Start Event → Pemohon menyusun dokumen → Submit ke Supervisor → Gateway: Disetujui/Perlu Revisi

Kalau perlu revisi, dokumen kembali ke Pemohon untuk diperbaiki, lalu disubmit ulang — proses ini bisa terjadi beberapa kali dalam bentuk loop. Kalau disetujui oleh Supervisor, dokumen naik ke Manager. Di level Manager ada Gateway lagi: kalau nilai atau dampak dokumennya di bawah threshold tertentu, Manager langsung menandatangani. Kalau di atas threshold, eskalasi ke Direksi. Setelah semua tanda tangan didapat, dokumen masuk ke sistem pengarsipan → End Event.

Yang paling berharga dari pemetaan proses ini adalah: setiap orang yang terlibat bisa melihat posisi dokumen secara real-time. Tidak ada lagi situasi "saya kira sudah selesai di sana." Kalau proses ini kemudian diotomatisasi ke dalam sistem digital, diagram BPMN-nya sudah bisa langsung dipakai sebagai spesifikasi workflow-nya.

Proses approval dokumen mungkin tampak trivial dibanding rekrutmen atau procurement. Tapi justru karena sering dianggap remeh itulah ia sering menjadi sumber frustrasi yang tidak kunjung selesai. Memetakannya dengan BPMN adalah langkah kecil yang dampaknya terasa nyata dalam keseharian.

Baca juga : 7 Langkah Pemodelan Bisnis Strategis Anti-Gagal

Contoh BPMN 4: Penanganan Keluhan Pelanggan

Pelanggan yang komplain itu sebenarnya masih mau memberikan kesempatan. Pelanggan yang pergi diam-diam tanpa komplain  itu yang jauh lebih berbahaya. Artinya, penanganan keluhan yang baik adalah peluang nyata untuk mempertahankan kepercayaan, bukan sekadar kewajiban administratif yang harus dicentang.

Tapi kalau proses penanganannya tidak jelas, staf customer service bisa terjebak dalam situasi yang frustasi: tidak tahu harus eskalasi ke mana, tidak ada standar waktu respons, dan tidak ada sistem untuk memastikan setiap keluhan benar-benar selesai ditangani.

Dengan notasi BPMN, alur penanganan keluhan bisa dipetakan dengan cukup detail. Prosesnya dimulai dari berbagai kanal masuk  email, telepon, chat, atau media sosial — dan bermuara ke satu alur yang terstandardisasi:

Start Event (Keluhan masuk) → Registrasi dan pencatatan di sistem → Identifikasi kategori keluhan → Gateway: Teknis / Non-Teknis / Permintaan Pengembalian

Masing-masing kategori mengalir ke tim yang berbeda dengan langkah penyelesaian yang berbeda pula. Setelah penyelesaian di masing-masing jalur, semua jalur bertemu di satu titik: konfirmasi ke pelanggan → Gateway: Pelanggan Puas/Tidak Puas

Kalau pelanggan belum puas, eskalasi ke supervisor atau tim khusus. Kalau sudah puas, tiket ditutup → End Event.

Dengan alur yang terpetakan seperti ini, perusahaan tidak hanya bisa mengukur waktu penyelesaian rata-rata per kategori keluhan  tapi juga mengidentifikasi di tahap mana paling sering terjadi kemacetan. Data itu yang kemudian menjadi dasar perbaikan proses secara berkala, bukan sekadar keputusan berdasarkan intuisi semata.

Contoh BPMN 5: Onboarding Karyawan Baru

Rekrutmen yang bagus bisa jadi sia-sia kalau onboarding-nya berantakan. Ini bukan hiperbola  ada riset yang menunjukkan bahwa pengalaman onboarding yang buruk secara signifikan mempengaruhi keputusan karyawan baru untuk bertahan atau tidak dalam tiga bulan pertama.

Masalah onboarding yang paling sering terjadi: tidak ada koordinasi antar departemen. Karyawan baru datang di hari pertama, tapi laptop belum disiapkan oleh IT. Atau akun email belum aktif. Atau manajernya tidak ada karena tidak tahu kapan karyawan barunya mulai. Kecil? Mungkin. Tapi kesan pertama itu susah dihapus.

Diagram BPMN untuk onboarding idealnya melibatkan empat swimlane sekaligus: HR, IT Support, Manajer Divisi, dan Karyawan Baru sendiri. Keempatnya bekerja secara paralel dan berurutan tergantung tahapannya:

Start Event → HR menyiapkan dokumen kontrak dan jadwal orientasi → secara paralel → IT menyiapkan akun, perangkat, dan akses sistem → Manajer menyusun rencana kerja 30/60/90 hari → Karyawan baru tanda tangan kontrak → Orientasi umum perusahaan → Pelatihan posisi spesifik → Evaluasi akhir masa percobaan → Gateway: Lulus/Tidak Lulus → End Event

Dengan BPMN, semua departemen tahu tugasnya masing-masing  dan yang lebih penting, tahu kapan mereka harus selesai agar tahap berikutnya bisa dimulai. Tidak ada lagi momen memalukan di mana karyawan baru duduk bengong di hari pertama karena tidak ada yang mempersiapkan apapun.

Lebih dari itu, diagram ini juga bisa menjadi checklist operasional yang konkret. HR tidak perlu mengingat-ingat apa saja yang harus disiapkan  cukup ikuti alur yang sudah terpeta. Dan kalau ada karyawan baru yang bergabung setahun kemudian, prosesnya akan sama konsistennya karena panduan visualnya sudah tersedia.

Mengendus 4 'Dosa' Operasional yang Diam-Diam Menguras Dompet Perusahaan 

Ini yang sering tidak disadari: nilai terbesar BPMN bukan hanya pada dokumentasinya, tapi pada proses pembuatannya itu sendiri.

Ketika tim duduk bersama dan mulai memetakan sebuah proses ke dalam diagram BPMN, hampir selalu ada momen "tunggu dulu  ternyata selama ini prosesnya seperti ini?" Proses yang selama bertahun-tahun berjalan berdasarkan kebiasaan tiba-tiba terlihat dengan jelas  termasuk bagian-bagian yang sebenarnya tidak masuk akal kalau dilihat secara objektif.

Ada empat jenis masalah yang paling sering terungkap ketika proses bisnis dipetakan dengan diagram BPMN:

Bottleneck tersembunyi, misalnya, sering kali muncul karena satu orang menanggung terlalu banyak keputusan. Di diagram BPMN, ini terlihat jelas: satu lane yang dipenuhi task sementara lane lain hampir kosong. Solusinya bukan bekerja lebih keras  tapi mendistribusikan ulang tanggung jawab secara lebih proporsional.

Duplikasi kerja lebih sulit dideteksi tanpa visualisasi. Tapi begitu dua lane terlihat sama-sama mengerjakan "verifikasi data" di tahap yang berbeda, pertanyaan langsung muncul: apakah keduanya memang perlu? Kalau salah satu bisa dihilangkan tanpa mengorbankan kualitas, mengapa tidak?

Langkah tanpa nilai tambah biasanya lolos bertahun-tahun karena "memang sudah dari dulu begitu." BPMN memaksa tim untuk mempertanyakan setiap langkah secara eksplisit. Dan kalau jawabannya adalah "kami tidak tahu kenapa langkah ini ada"  itu sudah cukup menjadi alasan untuk mengevaluasinya.

Standar BPMN 2.0 yang digunakan saat ini memungkinkan tingkat detail yang cukup tinggi untuk keperluan audit internal maupun penyusunan ulang alur kerja secara menyeluruh. Hasilnya: proses yang lebih terukur, lebih transparan, dan lebih mudah untuk terus diperbaiki dari waktu ke waktu.

Baca juga : Mengenal Strategic Alignment Model (SAM) : Pengertian, Konsep dan Elemen

Jangan Asal Gambar! Ini 7 Aturan Biar Diagram BPMN Anda Mudah Dibaca Awam 

Menguasai notasi BPMN secara teoritis itu satu hal. Membuat diagram yang benar-benar bisa dibaca  dan dipahami  oleh manajer yang belum pernah mendengar istilah "gateway" sebelumnya, itu hal yang berbeda.

Berikut tujuh tips praktis yang kerap diabaikan oleh analis bisnis pemula:

Mulai dari swimlane, bukan dari simbol. Sebelum menggambar apapun, identifikasi dulu siapa saja yang terlibat dalam proses dan bagi mereka ke dalam lane masing-masing. Ini adalah fondasi  salah di sini, seluruh diagram akan membingungkan.

Buat versi "as-is" yang sederhana lebih dulu. Jangan langsung mencoba menggambar proses ideal. Gambar dulu proses yang sekarang benar-benar terjadi, se-berantakan apapun. Validasikan ke orang-orang yang benar-benar menjalaninya. Baru setelah itu buat versi "to-be" yang sudah diperbaiki.

Gunakan pola penamaan yang konsisten. Setiap task sebaiknya dinamai dengan format Kata Kerja + Objek: "Kirim Invoice", "Review Dokumen", "Konfirmasi Penerimaan". Nama yang ambigu seperti "Handle" atau "Proses" tidak memberikan informasi apapun kepada pembaca.

Jaga jumlah gateway tetap wajar. Terlalu banyak percabangan dalam satu diagram membuat pembaca pusing. Kalau sebuah proses punya lebih dari lima atau enam gateway, pertimbangkan untuk memecahnya menjadi beberapa subprocess yang lebih kecil dan lebih mudah dicerna.

Sertakan legenda. Tidak semua pembaca diagram adalah analis bisnis. Tambahkan keterangan singkat tentang simbol-simbol yang dipakai  terutama kalau diagram menggunakan elemen yang lebih advanced seperti intermediate event, boundary event, atau compensation task.

Pilih tools yang sesuai kebutuhan. Ini sering diremehkan, tapi pilihan tools berpengaruh pada konsistensi dan kemudahan kolaborasi. Tabel perbandingan berikut bisa membantu:

Bizagi Modeler tetap menjadi pilihan paling populer di kalangan analis bisnis Indonesia  gratis, antarmukanya intuitif, dan mendukung standar BPMN 2.0 secara penuh.

Validasi bersama tim lintas divisi, bukan hanya IT. Diagram BPMN yang secara teknis benar tapi tidak mencerminkan realitas operasional adalah diagram yang tidak berguna. Libatkan perwakilan dari setiap divisi yang terlibat dalam proses. Sering kali, merekalah yang akan menemukan kesalahan atau kekurangan yang tidak terlihat dari sudut pandang analis.

Penutup

Ada kesalahpahaman yang masih sering terjadi: BPMN dianggap sebagai "alat teknis" yang cukup diserahkan ke tim IT atau tim analis sistem. Sisanya  manajer, staf operasional, bahkan direktur  tidak perlu terlibat terlalu dalam.

Padahal justru sebaliknya.

BPMN adalah alat komunikasi. Fungsinya bukan untuk menghasilkan dokumen teknis yang disimpan di server dan tidak pernah dibuka lagi  tapi untuk menciptakan satu versi kebenaran tentang bagaimana proses bisnis berjalan, yang disepakati dan dipahami oleh semua pihak yang terlibat. Diagram yang bagus adalah diagram yang bisa dibaca oleh manajer tanpa latar belakang IT sekalipun, dan tetap akurat secara logika bisnis.

Dari kelima contoh yang sudah dibahas  rekrutmen, procurement, approval dokumen, penanganan keluhan, hingga onboarding  semuanya punya satu kesamaan mendasar: prosesnya melibatkan banyak pihak, dan ketika tidak ada peta bersama, gesekan antar pihak hampir tidak bisa dihindari. BPMN bukan yang menghilangkan gesekan itu sepenuhnya. Tapi dengan diagram yang tepat, setidaknya semua orang tahu di mana mereka berdiri dan ke mana proses harus bergerak selanjutnya.

Kejelasan memang tidak gratis  perlu waktu dan kolaborasi untuk memetakannya. Tapi biaya investasi awal itu jauh lebih kecil dibanding biaya operasional yang terbuang karena proses yang terus-menerus membingungkan semua orang.

Kalau selama ini perusahaan masih mengandalkan email berantai dan dokumen Word sebagai "dokumentasi proses"  ini mungkin saat yang tepat untuk mulai bergerak. Tidak perlu langsung sempurna. Mulai dari satu proses yang paling sering bermasalah. Satu halaman. Satu swimlane. Setelah itu, sisanya akan mengikuti.

Jangan tunggu sampai operasional kantor Anda makin amburadul! Setiap hari tanpa alur yang jelas adalah biaya yang terbuang sia-sia. Amankan efisiensi bisnis Anda sekarang juga dengan menghubungi kami melalui tautan berikut. [Chat Tim Ahli Kami via WhatsApp] 

FAQ (Frequently Asked Questions)

1. Apa perbedaan utama antara BPMN dengan Flowchart biasa? 

Flowchart biasa bersifat bebas interpretasi, tidak memiliki aturan baku, dan hanya cocok untuk menggambarkan alur sederhana atau logika pemrograman dasar. Sementara itu, BPMN 2.0 memiliki standar notasi internasional yang ketat dan diakui secara global. BPMN mampu menggambarkan proses kompleks yang melibatkan banyak departemen (swimlane), interaksi antar-sistem, pesan paralel, hingga penanganan error secara presisi tanpa menimbulkan salah tafsir.

2. Siapa saja di dalam perusahaan yang harus bisa membaca diagram BPMN? 

Idealnya, semua pihak yang terlibat dalam proses bisnis tersebut harus bisa membacanya. BPMN dirancang sebagai jembatan komunikasi. Jadi, mulai dari staf operasional yang menjalankan tugas, manajer divisi yang mengambil keputusan, direksi yang meninjau efisiensi biaya, hingga tim IT yang akan membangun sistem otomatisasi, semuanya wajib memahami arti simbol-simbol dasar BPMN agar tidak terjadi miskomunikasi.

3. Apakah membuat diagram BPMN harus menggunakan aplikasi berbayar seperti Visio atau Lucidchart? 

Tidak harus. Untuk pemula atau tim yang membutuhkan kolaborasi cepat tanpa biaya, Anda bisa menggunakan draw.io atau Bizagi Modeler versi gratis. Bizagi Modeler bahkan sudah sangat mumpuni karena mendukung standar pembuatan BPMN 2.0 secara penuh dan memiliki tampilan yang sangat intuitif untuk para analis bisnis di Indonesia.

4. Berapa banyak Pool dan Lane (Swimlane) yang ideal dalam satu diagram? 

Tidak ada angka pasti, namun prinsip utamanya adalah menjaga keterbacaan. Gunakan 1 Pool utama untuk organisasi Anda, dan bagi menjadi beberapa Lane (misalnya Lane HR, Lane IT, Lane Finance) sesuai dengan jumlah peran yang terlibat. Jika prosesnya terlalu luas dan membutuhkan lebih dari 7 Lane atau melintasi organisasi yang berbeda ekosistem, sebaiknya gunakan Pool terpisah atau pecah diagram tersebut menjadi beberapa Sub-process kecil agar pembaca tidak pusing.

5. Mengapa format penamaan aktivitas (Task) di BPMN wajib menggunakan Kata Kerja + Objek? 

Format Kata Kerja + Objek (contoh: "Verifikasi Dokumen", "Kirim Invoice") wajib digunakan untuk menegaskan adanya tindakan nyata yang harus diselesaikan oleh pemilik Lane tersebut. Penggunaan kata yang ambigu atau hanya berupa kata benda (seperti "Proses" atau "Gudang") tidak memberikan kejelasan instruksi, rawan memicu kebingungan, dan mempersulit tim IT saat alur tersebut ingin diterjemahkan ke dalam sistem otomatisasi workflow.