BL
Hi,
I am trying to model our business processes. The business departments also want to model the “process steps” below.
• “Trigger request”
• “Hand over to …”
• “Assign order to next responsible”
• “Close task”
• “Create reference of App A in App B”
• “Inform Field Engineer”.
• “Ready for ...”.
For my opinion these Process Steps are not really Business Process (Steps). They are more technical (“HOW to do something”) and status changes. I wonder if we should model those. But the business wants to have them included.
What would you do? Can they be included in a business process model and if so how in BPMN or Value Chains?
Many thanks in advance
Ludwig
If you describe the technical BP for detailed solution then it can be described like that. System analysts and architect have to develop steps like that. If you are a business analyst, probably you can't choose the right solution and can't decompose big buseness steps to the litle technical steps.
Wed, 07/07/2021 - 06:44
When modeling processes this is a common question: to what granularity level do you define individual process steps. The rule I followed when I was managing a BPM CoE for a Dutch manufacturing company was OTOPOP: One Time One Person, One Place.
This meant that all the activities that One Person undertakes in One Place (meaning in the same application) at One Time (so consecutively) typically is modeled as one function (or one process step). Typically, this would be the level you model in your EPC or in the eBPMN format. If there is a need to become more detailed (like Pavel described above for technical purposes) than you can easily create a more technical model (often done in eBPMN then) and detail it out until the required level of detail.
Having said that, you might want to check out this post to learn that processes can have more than one purpose and you should model according to the primary purpose.
Good luck
Hi Ludwig,
For us this is the level of detail that we use. This is what our business needs, too.
The question when it comes to modeling is always the purpose, as @Caspar explained. I personally feel that there is no right or wrong, black or white, etc. Modelling also depends on the perspective. If you ask 3 different people how the process works, you'll get 4 answers. And this is not because they are working differently. This is often simply because they emphazise different aspects. From my perspecitve this is acutally what it takes to be a good process "modeller": you can balance all the different notions.
But coming back to the real question: if the individual process steps
1. cause issues in the current setup
2. are relevent for measurement/KPI/PPI (e.g.: to measure how many handovers took place, etc.)
3. reveil risks (e.g.: information chain gets broken)
4. are needed to create a step-by-step guideline with screenshots (the documentation attribute is handy for that)
5. etc.
Then, I would use that level of granularity as your business requires it.
Hope that answer helped a bit :)
Best,
Veronika
Hi Ludwig,
I am also an advocate of the OTOPOP principle as the granularity for a process level where you generally use either EPC or (E)BPMN Collaboration models for. The advantage is, that you have a clear criterion, what a process step is and when a new process step begins: You always have a change of responsibility (or place or time) from one step to the next. It's got another advantage, when you need the details you describe: For each step you can assign another more detailed process model I would call the "Work instruction", which is a common term everyone can relate to. You can use either another level in EPC notation or in case of EBPMN an EBPMN process diagram. You do not need Lanes in that, because due to the fact that the work instruction relates to a single process step under responsibility of a single set of roles described in the higher level process you won't have any change of responsibility. You can concentrate on the technical "How to", which was your intention in the first place.
One more technical hint. I had a customer who strictly used "Subprocess" (and Call Activity, that's another story) in the BPMN Collaboration diagrams only. This way every business process step was seen as a subprocess, which potentially could be expanded to the technical work instruction level with an assigned BPMN process diagram.
And one more remark regarding your examples "Hand over to..." and "Assign order to next responsible": I believe that these things follow naturally from your process model and need not be modelled as steps; when your work instruction comes to the process interface (or End event in EBPMN) the step of the business process is finished and you can see in the business process, what the next step is, which role is the next responsible, and which work instruction is to be followed for that step.
