Inilalarawan ng BPMN process diagram ang trabaho gamit ang Business Process Model and Notation: isang pamantayang wika para sa mga aktibidad, event, desisyon, at komunikasyon. Katumpakan ang halaga nito sa team review. Nagbibigay ang iisang modelo ng pagkakataon sa mga kalahok na kuwestiyunin ang isang partikular na transition sa halip na makipagtalo sa malalabong pahayag tulad ng “mabagal ang mga approval.”
Gumagamit ang artikulong ito ng maliliit at naglalarawang halimbawa para sa talakayan. Hindi ito mga executable na process model. Gumamit ng BPMN-capable na modeling tool para gawin at i-validate ang aktuwal na diagram. Sinusuportahan ng NextRetro ang retrospective discussion at follow-up; hindi ito BPMN editor o process engine.
Unawain ang notation bago bigyang-kahulugan ang larawan
Ang OMG BPMN 2.0.2 specification ang awtoritatibong sanggunian. Sadyang limitado ang gabay sa ibaba sa mga konseptong ginagamit sa halimbawa; mas marami pang detalye ang sinusuportahan ng BPMN.
| Elemento | Kahulugan sa halimbawang ito |
|---|---|
| Pool | Kalahok sa isang collaboration |
| Lane | Bahagi sa loob ng proseso; ginagamit dito para ipakita ang responsibilidad |
| Task | Aktibidad gaya ng pagsusuri ng request |
| Start o end event | Simula o katapusan ng mina-model na landas ng proseso |
| Gateway | Control point para maghiwalay o magsama ang mga landas |
| Sequence flow | Pagkakasunod-sunod ng gawain sa loob ng proseso; hindi tumatawid sa hangganan ng pool |
| Message flow | Komunikasyon sa magkakahiwalay na kalahok na ipinapakita bilang magkakahiwalay na pool |
Maaaring tumawid ang sequence flow sa mga lane sa loob ng iisang pool. Huwag gumamit ng message flow sa pagitan ng dalawang lane sa pool na iyon dahil lang magkaibang team ang gumagawa ng trabaho. Hindi mapagpapalit ang mga lane at mga hiwalay na kalahok.
Para sa mas detalyadong simbolo at gawi, tingnan ang normative specification. Nangangailangan ng mas mahigpit na validation ang modelong gagamitin sa automation kaysa sa sketch sa workshop.
Halimbawa 1: panloob na access request
Isipin ang isang kathang-isip na organisasyong nagsusuri kung paano humihiling ng access sa reporting system ang mga kawani. I-model ang organisasyon bilang isang pool na may mga lane para sa service desk at access administration. Maaari ring ipakita nang hiwalay ang empleyado kung itinuturing ng piniling collaboration view na isa siyang kalahok; piliin at idokumento nang pare-pareho ang hangganan.
Para sa proseso ng organisasyon, ganito ang simpleng landas:
- Dumarating ang request at sinisimulan ang proseso.
- Tinitingnan ng service desk kung kumpleto ang kailangang impormasyon.
- Hinahati ng exclusive decision ang kumpleto at kulang na mga request.
- Ibinabalik ang kulang na mga request para sa paglilinaw ayon sa napagkasunduang pakikipag-ugnayan sa requester.
- Ipinapasa ang kumpletong request para sa awtorisadong pagsusuri ng access.
- Binibigyan ng access ang mga aprubado; binibigyan naman ng paliwanag ang mga tinanggihan.
- Nagtatapos ang proseso sa pagtatala ng naaangkop na resulta.
Lagyan ng kundisyon ang mga decision path gaya ng “kumpleto ang kinakailangang impormasyon” at “kulang ang impormasyon.” Mahirap unawain ang “Oo” at “Hindi” kapag ibinahagi ang diagram nang wala ang orihinal nitong tanong.
Paglalarawan ito na dapat i-model, hindi pahayag na tumutupad ang mga hakbang sa patakaran ng seguridad ng isang partikular na organisasyon. Dapat manggaling sa mga aprubadong kontrol ng organisasyong iyon ang mga kinakailangan sa pag-apruba ng access at ebidensya.
Halimbawa 2: may kontribusyon ang supplier sa proseso
Ngayon, isipin na kailangang mag-activate ng hiwalay na supplier ng lisensiyadong account matapos itong pahintulutan ng organisasyon. Ipakita ang supplier bilang isa pang pool. Komunikasyon sa pagitan ng mga kalahok ang activation request ng organisasyon at ang kumpirmasyon ng supplier, kaya i-model ang mga ito bilang message flow.
Huwag gumuhit ng sequence arrow mula sa panloob na task papunta mismo sa task ng supplier. Malilito rito ang panloob na pagkakasunod-sunod ng proseso ng isang kalahok at ang komunikasyong tumatawid sa hangganan.
Maaari mong itago ang panloob na proseso ng supplier kung wala ito sa saklaw ng review. Maaaring kailangan malaman ng team kung anong mensahe ang nagsisimula sa pakikipag-ugnayan sa supplier at anong sagot ang inaasahan, nang hindi nagpapanggap na alam nito ang panloob na paraan ng paggawa ng supplier.
Makikita na ngayon ang isang kapaki-pakinabang na tanong sa review: ano ang mangyayari kung walang kumpirmasyong dumating? Itakda muna ang inaasahang paghawak sa exception bago magdagdag ng timer o iba pang event sa pormal na modelo. Hindi itinatakda ng label na timeout kung sino ang magfa-follow up o anong desisyon ang maaari niyang gawin.
Sundan ang mga kaso sa modelo bago ito baguhin
Pumili ng tatlong totoong kasong naaangkop ang pagkakakubli ng pagkakakilanlan: isang karaniwang nakumpleto, isang nangangailangan ng paglilinaw, at isang exception. Panatilihin ang personal at kumpidensiyal na detalye sa aprubadong case system; gumamit ng reference o buod sa workshop.
Sa bawat kaso, hilingin sa mga gumawa ng trabaho na sundan ang landas nito. Saan talaga natigil ang trabaho? Anong impormasyon ang kulang? Sinong kalahok ang nag-akala na ibang tao ang may-ari ng susunod na hakbang? Itala ang mga pagkakaiba ng dokumentadong proseso at nakitang gawain.
Huwag tahimik na baguhin ang modelo para maging ideal na prosesong panghinaharap. Ihiwalay ang kasalukuyang landas at ang iminungkahing pagbabago. Kung hindi, maaaring umalis ang team na dala ang maayos na diagram na hindi na nagpapaliwanag sa mga kasong dapat nitong siyasatin.
Palagay ang isang process model tungkol sa daloy ng trabaho. Nakakatulong ang mga timestamp at kasaysayan ng kaso para subukan ang palagay na iyon. Hindi sapat na kumpletong ebidensya ang diagram o ang alaala ng isang kalahok lamang.
Halimbawa ng isang desisyon para sa pagpapahusay
Sa kathang-isip na halimbawang ito, sinusuri ng team ang labindalawang request. Para lamang ito sa pagpapaliwanag, hindi benchmark o resulta ng customer ng NextRetro. May ilang request na naghintay sa pagitan ng pagsusuri ng impormasyon at pag-apruba ng access dahil hindi tinukoy ng handoff kung sino ang gagawa ng desisyon.
Ang unang panukala ay i-automate ang bawat approval. Ipinapakita ng modelo kung bakit napaaga ito: hindi pa napagkasunduan ng team kung aling mga request ang nangangailangan ng aling pahintulot. Maaaring pabilisin ng automation ang hindi kumpletong trabaho nang hindi nilulutas ang responsibilidad.
Mas maliit na pagsubok ang pinili ng team. Para sa susunod na sampung kwalipikadong request, tutukuyin muna ng service desk ang may-ari ng approval bago ipadala ang handoff. Hiwalay na itatala ang oras ng paghihintay para linawin ang may-ari at ang oras ng mismong pag-apruba.
Hindi nagbabago ang proteksyon: pareho pa rin ang access control. Hindi dahilan ang mas mabilis na paghawak para laktawan ang approval. Sa susunod na review, susuriin ng team kung nabawasan ang mga pagkaantalang dulot ng hindi malinaw na may-ari at kung nakagawa ng bagong bottleneck ang dagdag na paghahanda.
Iniuugnay nito ang process diagram sa nakikitang pagbabago sa halip na ituring na pagpapahusay ang pagtatapos ng diagram.
Gumamit ng review worksheet kasabay ng diagram
Itala ang mga sumusunod para sa bawat pinaghihinalaang problema:
Lokasyon: Aling task, desisyon, o handoff ang apektado?
Nakitang kaso: Aling halimbawa ang nagpapakita ng problema?
Inaasahang trigger: Ano ang dapat magsimula sa susunod na hakbang?
Tunay na hadlang: Ano ang pumigil dito?
Iminungkahing pagbabago: Ano ang mag-iiba sa susunod na kwalipikadong kaso?
Limitasyon: Aling kontrol o pangangailangan sa kalidad ang dapat manatili?
Ebidensya para sa review: Ano ang susuriin ng team at kailan?
Pumili ng retrospective format na magbibigay sa mga kalahok ng oras para kuwestiyunin ang modelo bago unahin ang mga pagbabago. Pagkatapos, gamitin ang gabay sa action item para manatiling nakikita ang napiling eksperimento matapos ang meeting.
Mga madalas itanong
Pareho ba ang pool at lane sa BPMN?
Hindi. Kumakatawan ang pool sa isang kalahok sa collaboration. Hinahati ng lane ang proseso. Maaaring tumawid ang sequence flow sa mga lane sa loob ng pool; gumagamit naman ng message flow ang komunikasyon sa pagitan ng magkakahiwalay na pool ng mga kalahok.
BPMN diagram ba ang bawat process flowchart?
Hindi. Maaaring gumamit ang pangkalahatang flowchart ng di-pormal na simbolo at kombensiyon. Tawagin lamang na BPMN ang modelo kung sumusunod ito sa mga naaangkop na tuntunin ng notation, at i-validate ito nang wasto kung gagamitin sa automation.
Makakagawa ba ang NextRetro ng executable na BPMN model?
Hindi BPMN modeling tool o process engine ang NextRetro. Itago ang opisyal na modelo sa angkop na editor at gumamit ng retrospective board para pag-usapan ang mga nakitang problema, magkakaibang paliwanag, at napagkasunduang eksperimento para sa pagpapahusay.