Occasionally I get BPMN diagrams like this:
This is the “Payment process” composed of interacting “Accounting department process”, “Business unit finance department process” and “Corporate finance department process.”
Formally it’s a correct BPMN but in essence, it isn’t a business process. “Accounting department business process” is nonsense. Another nonsense is the “Employee daily business process” starting at 9:00 am. The argument “but we’re working this way so it’s our as-is process” doesn’t work. Our activities can be considered from different perspectives - there is functional view and process view.
It’s difficult to explain what is a process view to people who are accustomed to think functionally. I have this issue rather often with IT people whose job is automating functions. They view the world around like this:
- Here is an employee A and here is an application screen for his/her job. He/she should pressed F5 regularly throughout the day to see submitted bills and transfer them from “received” to “approved” or “rejected”.
- And here is employee B and an application screen where he/she can see the approved bills. They should be transferred to “accomplished” - it’s the business process.
How to switch from functional to process thinking?
Tell us “the story of the bill.”
Forget about performers for a while and take a look at the same set of activities from business object perspective. For the process under consideration the bill is such a business object. Tell us the story of a single bill: what happens to it? Who, what, in what sequence should do with it? One bill is one instance of the business process.
And then you’ll get quite different diagram:
It’s a paradox that only advanced BPMN users who’ve got the idea of modeling inter-process communication become the victims of functional mindset. Business people knowing only basic BPMN elements intuitively get the true process view; they’d hardly understand the first diagram, let alone drawing something like this.