Have you ever seen process models with task names like “Prepare report and get approval” and wondered if this is how it should be done?
Recently I had a nice discussion with participants of my BPMN training and noticed that it is not obvious for everyone how to split the processes into tasks.
From BPMN spec we know that:
An Activity is a generic term for work that company performs in a Process. An Activity can be atomic or non-atomic (compound).
…
A Task is an atomic Activity that is included within a Process. A Task is used when the work in the Process is not broken down to a finer level of Process detail.
OK. But how does it help us in practice?
Below you can find few tips I shared regarding possible criteria. I hope they will help you name your tasks better:
- Responsibility change
- Changes of documents/data we are working on
- Changes of IT support
Let’s start with a first one: you know it is time to split the tasks when you have a change in responsibility (RACI can be helpful here). So if you need to prepare a document (on your own) and than get an approval (which obviously requires some other people involvement) this should not be one task, but two.
For the second one – if during your process you start working with a different set of documents or the state of your document changes (think of BPMN Data Objects) this may be used as a hint that new task is needed.
And last, but not least – IT support. If some process steps are done manually, while some are IT supported they should be split.
You may ask why do we do it? Firstly – it is nice to have process models with 10 or less tasks, but if they have long and complex names you will not have better readability. Secondly – if the tasks are really atomic activities it is much easier to perform process analysis and improvement.
Do you use other ways to split your processes? Post them in comments!