Archyno
BPMNPrax modelovania

Ako nakresliť BPMN diagram

Šesť krokov v poradí, ktoré udrží procesný diagram poctivý: pomenujte oba konce skôr než stred, nakreslite cestu, na ktorej nič nezlyhá, a až potom pridajte vetvenia, výnimky a účastníkov, ktorých neriadite.

9 min čítaniaBPMN 2.05 z 6

RecruitingVacancyapprovedWrite advertReview wordingPost advertAdvert live
What the process looks like after step three: one pool, one line, no branches. Almost every bad BPMN diagram is one that skipped this stage and started adding gateways while the middle was still being argued about.

01Step 1. Fix both ends before the middle

Write down the event that starts the process, then every distinct way it can finish. Not the steps - the ends. This takes two minutes and it is where the disagreements are.

"Recruiting" is not a process. "From an approved vacancy to a live advert" is: it has one trigger and a stated finish, so two people can now disagree about whether shortlisting is inside it, cheaply, before anything has been drawn.

Name more than one end event if the process has more than one outcome. A process that can be rejected and does not show rejection as an ending is a process the diagram is lying about.

02Step 2. List the steps as verbs

Before any shapes, write the steps as a plain list, each one a verb and an object: write advert, review wording, post advert. The naming rule is doing work here rather than enforcing style.

  • A noun on its own - Advert - hides whether it is written, checked or published.
  • A passive form - Advert is reviewed - hides who reviews it, which is the question the pool has to answer later.
  • A name containing and is two tasks, or it is a subprocess. Split it now, while it is a line of text rather than a box with four edges attached.

03Step 3. Draw only the path where nothing goes wrong

One pool, left to right, start event to end event, no gateways at all. This is the figure at the top of this article, and it should feel too simple - that is the point.

The happy path is the spine everything else hangs from, and drawing it alone forces the question of what normally happens to be settled before the question of what occasionally happens. Diagrams built the other way round tend to have three exception branches and no clear main line, which is how a process diagram ends up being read by nobody.

Keep it on one horizontal line. Bending the main path around a corner to fit the page costs a reader more than a wide diagram does.

04Step 4. Add the branches and the loops

RecruitingJob boardyesnoadvertVacancyapprovedWrite advertWording approved?Post advertAdvert liveRevise wording
The same process after steps four and five: a decision, the rework loop it implies, and the participant who actually publishes the advert. The happy path is still a straight line across the middle, which is what keeps it readable.

Now ask, at each step, what else can happen. Every answer is a gateway, and the marker in it is the whole decision:

  • Exactly one path - exclusive gateway, the rhombus with an X.
  • All paths, always - parallel gateway, the plus. Remember the join waits for every branch.
  • One or more, depending - inclusive gateway, the circle. Powerful and the easiest to deadlock, so balance every split with its join.
  • Whichever happens first - event-based gateway. It decides nothing, it waits.

Then add the loops, because this is the step people skip. If work can be sent back, draw the flow back to the task that repeats - not to the gateway that noticed the problem. The full set of five rhombi and when each is right is in BPMN gateways.

05Step 5. Add a second pool only if you must

A second pool is expensive: sequence flow may not cross a pool boundary, so everything between the two becomes a message, and the diagram gets taller. Pay that cost for one reason only - there is a participant you do not control and cannot instruct.

A customer, a supplier, a payment provider, a job board: those are pools. Your own departments are not. Finance and legal both work for the same organisation and sequence flow has to be able to run between them, so they are lanes inside one pool.

When you do add one, consider leaving it empty. A collapsed pool says the messages are known and the internals are not, which is usually the honest position and stays true when the other party changes how they work.

06Step 6. Run five checks

Quick, mechanical, and between them they catch most of what goes wrong:

  1. Every path reaches an end event. Follow each branch with a finger. A path that stops at a task is a token stranded forever.
  2. Every split has its join. Particularly parallel and inclusive ones - an unbalanced pair is the standard way to deadlock a process.
  3. Every task is a verb and an object. The names that fail this are the steps nobody has thought through.
  4. No sequence flow crosses a pool boundary. One glance along each boundary line.
  5. Somebody who does the work has read it. This finds more defects than the other four together, and it is the only one that catches a diagram that is internally perfect and describes the wrong process.

In one line each

  1. 01Name the trigger and every ending before drawing any step.
  2. 02Steps are verb plus object; a name containing 'and' is two tasks or a subprocess.
  3. 03Draw the happy path alone first, on one horizontal line, in one pool.
  4. 04Add gateways only after the main line is settled, then add the rework loops.
  5. 05Loop back to the task that repeats, not to the gateway that detected the problem.
  6. 06A second pool is for participants you do not control; your own departments are lanes.
  7. 07Five checks: every path ends, every split joins, verbs, no flow across pools, and a human review.

Five complete processes built this way are in BPMN examples, and every symbol used along the way is indexed in the BPMN symbol reference.

07Časté otázky

Aký je prvý krok pri kreslení BPMN diagramu?

Ustáliť oba konce skôr, než sa nakreslí čokoľvek v strede. Zapíšte jedinú udalosť, ktorá proces spúšťa, a každý odlišný spôsob, ako sa môže skončiť - spor o rozsah tak nastane hneď a lacno, nie až po dvadsiatich boxoch na papieri. Väčšina nezhôd o procese sú v skutočnosti nezhody o tom, kde začína a čo znamená hotovo.

Má sa BPMN diagram čítať zľava doprava alebo zhora nadol?

Zľava doprava, s bazénmi ukladanými pod seba. Nie je to v špecifikácii, ale takto to štandardne robí každý nástroj a takto to čitatelia očakávajú, takže proces zhora nadol stojí zrozumiteľnosť a nič neprináša. Šťastnú cestu držte na jednej vodorovnej línii a vetvy výnimiek posuňte nad ňu alebo pod ňu.

Ako sa majú pomenovať úlohy v BPMN diagrame?

Sloveso plus predmet, v činnom rode: Schváliť faktúru, Odoslať objednávku, Informovať zákazníka. Samotné podstatné meno ako Faktúra nepovie, či sa vytvára, kontroluje alebo platí, a trpný rod skryje, kto koná. Ak názov úlohy potrebuje slovo a, sú to dve úlohy alebo je to podproces.

Aký nástroj použiť na kreslenie BPMN diagramu?

Ľubovoľný, ktorý exportuje BPMN 2.0 XML, nielen obrázok - diagram uväznený v obrázkovom súbore sa nedá validovať, porovnávať ani spúšťať. Inak na voľbe záleží menej, než naznačuje väčšina porovnaní: notácia je štandard, takže sledovať treba exportný formát, nie kresliacu plochu.

Ako spoznať, že je BPMN diagram hotový?

Keď každá cesta končí koncovou udalosťou, každá deliaca brána má svoju spájaciu, každý názov úlohy je sloveso a predmet, žiadny sekvenčný tok neprekračuje hranicu bazéna a niekto, kto tú prácu naozaj robí, si to prečítal a neopravil vás. Posledná kontrola nájde viac chýb než ostatné štyri dokopy.

ZdieľaťXLinkedIn
Všetky články: BPMN
Všetky články