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 next—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.

Oh, yes. In addition to voluntarily initiated processes, there are also processes that automatically start with an incoming message.

Think back to the train and tracks. It's okay if there are multiple starting stations or terminal stations.

You miss nothing.

Are you mocking me?

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.

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.