Diagram proses BPMN menggambarkan pekerjaan menggunakan Business Process Model and Notation, bahasa standar untuk aktivitas, peristiwa, keputusan, dan komunikasi. Nilainya dalam tinjauan tim adalah ketepatan. Model bersama membantu peserta mempertanyakan transisi tertentu, alih-alih berdebat tentang pernyataan samar seperti “persetujuan lambat”.
Artikel ini menggunakan contoh kecil yang deskriptif untuk diskusi. Contoh ini bukan model proses yang dapat dijalankan. Gunakan alat pemodelan yang mendukung BPMN untuk membuat dan memvalidasi diagram sesungguhnya. NextRetro mendukung diskusi retrospektif dan tindak lanjut; aplikasi ini bukan editor BPMN atau mesin proses.
Pahami notasi sebelum menafsirkan gambar
Spesifikasi OMG BPMN 2.0.2 adalah rujukan resmi. Panduan berikut sengaja dibatasi pada konsep yang digunakan dalam contoh kami; BPMN mendukung lebih banyak detail daripada yang dibahas di pengantar ini.
| Elemen | Makna dalam contoh ini |
|---|---|
| Pool | Peserta dalam kolaborasi |
| Lane | Bagian dalam suatu proses, digunakan di sini untuk menunjukkan tanggung jawab |
| Task | Aktivitas, seperti memeriksa permintaan |
| Event awal atau akhir | Awal atau akhir jalur proses yang dimodelkan |
| Gateway | Titik kendali untuk mencabangkan atau menggabungkan jalur |
| Sequence flow | Urutan kerja dalam satu proses; tidak melintasi batas pool |
| Message flow | Komunikasi antara peserta terpisah yang digambarkan sebagai pool berbeda |
Sequence flow dapat melintasi lane di dalam pool yang sama. Jangan gunakan message flow antara dua lane dalam pool itu hanya karena tim berbeda mengerjakan tugasnya. Lane tidak sama dengan peserta mandiri.
Untuk simbol dan perilaku terperinci, lihat spesifikasi normatif. Model yang akan mengendalikan otomatisasi membutuhkan validasi lebih ketat daripada sketsa lokakarya.
Contoh 1: permintaan akses internal
Bayangkan organisasi hipotetis yang meninjau cara staf meminta akses ke sistem pelaporan. Modelkan organisasi sebagai satu pool dengan lane untuk meja layanan dan administrasi akses. Karyawan dapat digambarkan terpisah jika tampilan kolaborasi yang dipilih menganggap pemohon sebagai peserta lain; pilih dan dokumentasikan batasnya secara konsisten.
Untuk proses organisasi, jalur sederhananya adalah:
- Permintaan masuk dan memulai proses.
- Meja layanan memeriksa apakah informasi yang diperlukan sudah tersedia.
- Keputusan eksklusif memisahkan permintaan lengkap dan tidak lengkap.
- Permintaan yang tidak lengkap dikembalikan untuk klarifikasi sesuai interaksi yang ditetapkan dengan pemohon.
- Permintaan lengkap diteruskan untuk pemeriksaan akses yang berwenang.
- Permintaan yang disetujui mendapat akses; permintaan yang ditolak mendapat penjelasan.
- Proses berakhir dengan hasil yang sesuai dan tercatat.
Beri label pada jalur keputusan dengan kondisi seperti “informasi wajib lengkap” dan “informasi belum lengkap”. Label “Ya” dan “Tidak” sulit ditafsirkan saat diagram dibagikan tanpa pertanyaan asalnya.
Ini adalah uraian untuk dimodelkan, bukan klaim bahwa langkah-langkahnya memenuhi kebijakan keamanan organisasi tertentu. Persyaratan otorisasi akses dan bukti harus berasal dari kontrol yang disetujui organisasi tersebut.
Contoh 2: pemasok berkontribusi pada proses
Sekarang bayangkan pemasok terpisah harus mengaktifkan akun berlisensi setelah organisasi memberikan otorisasi. Gambarkan pemasok sebagai pool lain. Permintaan aktivasi dari organisasi dan konfirmasi pemasok adalah komunikasi antarpeserta, jadi modelkan sebagai message flow.
Jangan menggambar panah sequence dari task internal langsung ke task pemasok. Tindakan itu mencampur urutan kerja internal satu peserta dengan komunikasi yang melintasi batas.
Proses internal pemasok dapat disembunyikan jika berada di luar cakupan tinjauan. Tim mungkin perlu mengetahui pesan apa yang memulai interaksi pemasok dan tanggapan apa yang diharapkan tanpa berpura-pura memahami cara kerja internal pemasok.
Pertanyaan tinjauan yang berguna kini terlihat: apa yang terjadi jika konfirmasi tidak diterima? Tentukan penanganan pengecualian sebelum menambahkan timer atau event lain ke model formal. Label batas waktu saja tidak menetapkan siapa yang menindaklanjuti atau keputusan apa yang dapat diambilnya.
Telusuri kasus melalui model sebelum mengubahnya
Pilih tiga kasus nyata yang sudah disamarkan dengan semestinya: satu penyelesaian rutin, satu permintaan yang membutuhkan klarifikasi, dan satu pengecualian. Simpan detail pribadi dan rahasia di sistem kasus yang disetujui; gunakan referensi atau ringkasan dalam lokakarya.
Untuk setiap kasus, minta orang yang mengerjakan proses menelusuri jalurnya. Di mana pekerjaan sebenarnya berhenti? Informasi apa yang kurang? Peserta mana yang mengira orang lain bertanggung jawab atas langkah berikutnya? Catat perbedaan antara proses terdokumentasi dan praktik yang diamati.
Jangan diam-diam mengedit model agar menjadi proses masa depan yang ideal. Tandai jalur saat ini dan perubahan yang diusulkan secara terpisah. Jika tidak, tim dapat pulang membawa diagram rapi yang tidak lagi menjelaskan kasus-kasus yang seharusnya diselidiki.
Model proses adalah hipotesis tentang aliran kerja. Stempel waktu dan riwayat kasus membantu menguji hipotesis tersebut. Diagram maupun ingatan peserta bukan bukti lengkap dengan sendirinya.
Contoh keputusan perbaikan
Dalam contoh hipotetis ini, tim meninjau dua belas permintaan. Jumlah ini hanya untuk ilustrasi, bukan tolok ukur atau hasil pelanggan NextRetro. Beberapa permintaan menunggu di antara pemeriksaan informasi dan otorisasi akses karena serah terima tidak menyebut pemilik keputusan.
Usulan pertama adalah mengotomatiskan semua persetujuan. Model menunjukkan alasan usulan itu terlalu dini: tim belum menyepakati permintaan mana yang membutuhkan otorisasi tertentu. Mengotomatiskan keputusan yang belum didefinisikan dapat mempercepat pekerjaan yang belum lengkap tanpa menyelesaikan tanggung jawab.
Tim memilih eksperimen yang lebih kecil. Untuk sepuluh permintaan berikutnya yang memenuhi syarat, meja layanan akan mengidentifikasi pemilik otorisasi sebelum mengirim serah terima. Waktu menunggu klarifikasi pemilik dicatat terpisah dari waktu pelaksanaan otorisasi.
Pengamannya tetap sama: kontrol akses tidak berubah. Penanganan yang lebih cepat tidak membenarkan melewatkan otorisasi. Pada tinjauan berikutnya, tim akan memeriksa apakah keterlambatan karena pemilik yang tidak jelas berkurang dan apakah persiapan tambahan menciptakan hambatan baru.
Dengan demikian diagram proses terhubung ke perubahan yang dapat diamati, alih-alih menganggap diagram yang selesai sebagai perbaikan.
Gunakan lembar kerja tinjauan bersama diagram
Catat bidang berikut untuk setiap masalah yang dicurigai:
Lokasi: Task, keputusan, atau serah terima mana yang terdampak?
Kasus yang diamati: Contoh mana yang menunjukkan kesulitan?
Pemicu yang diharapkan: Apa yang seharusnya memulai langkah berikutnya?
Hambatan sebenarnya: Apa yang mencegahnya?
Perubahan yang diusulkan: Apa yang akan berbeda pada kasus berikutnya yang memenuhi syarat?
Batasan: Kontrol atau persyaratan mutu apa yang harus tetap berlaku?
Bukti tinjauan: Apa yang akan diperiksa tim, dan kapan?
Pilih format retrospektif yang memberi peserta waktu untuk mempertanyakan model sebelum memprioritaskan perubahan. Setelah itu, gunakan panduan butir tindakan agar eksperimen terpilih tetap terlihat setelah rapat.
Pertanyaan umum
Apakah pool dan lane sama dalam BPMN?
Tidak. Pool mewakili peserta dalam kolaborasi. Lane membagi suatu proses. Sequence flow dapat melintasi lane dalam satu pool, sedangkan komunikasi antarpool peserta yang berbeda menggunakan message flow.
Apakah setiap flowchart proses merupakan diagram BPMN?
Tidak. Flowchart umum dapat menggunakan simbol dan konvensi informal. Sebut model sebagai BPMN hanya jika mengikuti aturan notasi yang relevan, dan validasi dengan tepat jika akan digunakan untuk otomatisasi.
Dapatkah NextRetro membuat model BPMN yang dapat dijalankan?
NextRetro bukan alat pemodelan BPMN atau mesin proses. Simpan model resmi di editor yang sesuai dan gunakan papan retrospektif untuk membahas masalah yang diamati, penjelasan yang bersaing, dan eksperimen perbaikan yang disepakati.