You’d simplify BPMN work and at the same time make resulting diagrams simpler and clearer by accepting the following assumptions:
- All information is stored
- Organization has a mechanism of tasks assignation and transfer
- Every task is accompanied by appropriate instruction
- Every task has standard duration and there is a way to control it
1. All information is stored
Don’t ask how and where process data (attributes) are stored. Just take for granted that there is some dedicated storage and you are able to handle it.
E.g. you may have a RDBMS and you know how to design data structures - your engineers are familiar with the 3rd normal form, Entity-Relations diagrams, SQL etc.
Of course we won’t abandon the data design completely and will need to set it up sooner or later. But later is better because whenever there is an opportunity to divide a complex task into two relatively independent - process and data modeling in this case - one should utilize it because it simplifies things considerably.
Example: Tender process –
Question: What data are used to choose the winner?
Answer: There are proposals received from candidates (and probably their ratings) resulting from “Get a proposal” subprocess.
It’s enough - we can do the process design in assumption that proposals received from candidates are stored somewhere and are available for the following process tasks. It doesn’t really matter exactly how they are stored - in paper, Excel sheets obtained by email, XML documents obtained through e-commerce or as a relational table.
Now if we are going to not just model the process but also to automate then we’ll have to work on the data scheme as soon as the process scheme is ready. For example, the E-R diagram of the tender process data may look like this:
Later when the process will be modified, the data model will be amended as well. But don’t try combine these two aspects in one diagram - there are proven instruments for data modeling and BPMN is for the process part.
Although there are data objects and data stores in BPMN, they are a kind of “second-class citizens”: the control flows are obligatory in BPMN while the data flows are optional.
It sounds unusual for certain analysts and may even cause rejection. The background in other notations may form a habit to use data objects and data flows abundantly like in the following example:
Does the data object “Order” helps better understanding? I’d say no: if one task is named “Fill the order” and the other “Accept the order” then we may rightfully assume that the process has an “Order” attribute.
This is why I rarely use the data objects - only when they are non-obvious yet essential to understand the logic. As an example, it makes sense to depict the “Expenses report” attached to the process task “Perform the trip”:
Inter-process collaboration is a special case. Unlike in orchestration, the data flows are essential for process logic understanding here:
More on the matter:
To be continued…