Now that you have learned to draw BPMN, (Who… me?!) you will no doubt start looking for chances to use your new skill. First, take our word and try our BPMN Initiation Program: the Document Creation Process. It can be anything: daily reports, proposals, meeting documents, etc. Just make sure to imagine a process that will elicit the boss’s smile.

There can be many different examples, but a good sample might look like this:

“Ah, a peer review!“
In TV dramas the character would say, “I’ve finished the document you wanted,” and the boss would answer, “Good. By the way Mr. Tanaka…” But real life is never so easy.

When you hand in a finished draft, you more often than not are told about additional important points (for the first time), and when you fix that you will be told to enhance the layout design a little more, and then comes comments on typos, etc. There are too many organizations where this type of repetition is the norm.

When we aren’t so sure about ourselves we can ask a peer to review our work and utilize common expertise. At least it will increase the chance of getting the boss to smile.

Just to let you know, we didn’t consider the chance of no one accepting the reviewing task. Imagining such a merciless work environment would make the process way too complicated, in which case it would be better to design a process without a peer review in the first place!

“Wait a second… a new icon!“
Yes, a new character. But I think you get the basic idea of it. In short, an email is sent. This icon is pretty convenient. In this example it means an email is sent to peers for recruiting reviewers, although the icon itself does not explain who sends an email to whom. But, hey, that’s modeling. By the way, this is officially called a Message Throwing Intermediate Event, but you really don’t have to memorize the names.

As with natural languages and programming languages, it is important to begin by trying BPMN out. Forget about the exact grammar and official names. (If you have a lot of time on your hands, just remember that intermediate events have tramline borders, while start events have single narrow borders and end events have single bold borders.) BPMN-savvy people collectively call icons Flow Objects (events and tasks). Please beware. (Of the people or of the words?)

As with general rules and manuals, veteran employees usually don’t want to look at business processes drawn in BPMN. To be frank, they will not comply. After all, model diagrams are merely miniatures of reallife processes, and are hardly adequate to excite anyone who already does them everyday. And in some cases, employees will have their own way of doing things, and they don’t want to comply.

But BPMN diagrams don’t want to be filed away and forgotten. (You still there?) Especially if you worked hard at drawing them out. (Helloooo…?)

BPMN works best when implemented on work processes which are executed by many people in the same way , and in which roles are clear. To be specific, translation processes, quality check processes, and technical support processes are some good ones.

To put it clearly, if the effort improves something, it should be undertaken, but if it doesn’t, it shouldn’t.

When drawing business processes with BPMN, if the targeted process has few problems, there is less reason to draw it in BPMN. When you get used to it, drawing in BPMN becomes fun, but the act of drawing should never become the purpose. So let’s look at an inquiry-reaction process in which replies are too slow.


There is no upstream or downstream, no clear flow from one person to the nex — this almost doesn’t deserve to be called a business process. It has a lot of problems that
don’t even need BPMN to fix, but sadly, this is often reality. This is when mailboxes
become “Graveyards for tasks.”

What do you think? We made a business process in which the employee creates a reply with the help of the Technical department’s advice and the leader’s assessment. Defining business processes that do not allow tasks to be neglected is one of the duties of upper
management.

“There’s a letter inside the start icon (start event)!“
Oh, yes. In addition to voluntarily initiated processes, there are also processes that automatically start with an incoming message.

“So it’s okay to have two start icons!“
Think back to the train and tracks. It’s okay if there are multiple starting stations or terminal stations.

“A white letter and a black letter?“
You miss nothing. The details of this is explained in “BPMN for Beginners.” Basically, the white letter was written by Victor Hugo and the black letter by his publisher. (Are you mocking me?)

As we’ve explained so far, BPMN is a notation method for clearly illustrating real-life business processes. But perhaps you’ve noticed, some very important points are missing. For example, BPMN cannot recognize the format of the data to be handed down through tasks.

Also, it is often efficient for members executing upstream tasks to control the range of members for downstream tasks, but BPMN itself cannot clarify this. BPMN illustrates the overall framework, and doesn’t sweat over the small stuff.