I have a very big high level process. I want to now get into the detail but not sure of the approach. I have labelled the steps on the high level process 1.1, 1.2, 1.3…
Although I have labelled as high level, I am not sure if it is accurate to say it is high level as one step is ‘inform customer.’ Nonetheless it is still an end to end process.
For the next level down I was planning on expanding on these steps and treat as individual processes with the following step numbering e.g. 1.1.1, 1.1.2, 1.1.3.
I have not treated the detailed processes as sub processes as they are fairly big processes within the selves. My understanding is that sub processes are used only for a much lower level of detail?
I think this is a better approach than categorising them into groups e.g group 1 will focus on steps from 1.1 - 1.11 for example.
Please advise on the best approach.
The way to deal with complexity since the Roman Empire is Divide et Impera, which means cut it into smaller pieces until arriving at a level you can master.
In BP modelling, if your end-to-end process is too big to deal with, it probably means that you are modelling at a too detailed level. Here the strategy is to take a deep breath, zoom out, and find the big blocks that really matter without getting distracted by implementation details, and let the details for another level.
Doing so, you will probably discover that some sub-processes are not necessarily performed in sequence. Presenting too many details too early might hide this fact, and give impression of a big monolithic process, when in reality it's a set of interconnected dynamic and flexible processes. This is why the borderline between process and process groups can be somewhat fuzzy, and often more a convention than an objective reality.
Let me take the example of order to cash. It might be tempting to see one big end to end process starting by the reception of an order, searching for the customer in the database or create it, picking the items, delivering items, invoice the items, monitor incoming payments, and if delayed send the dunning letters. At this level it's already quite complex (I didn't even mention credit control, variants requiring prefinancing, and the logistic organisation of the warehouse or the transports).
If you get too early into details, like "print a notification", "send the notification", etc... you will have a cluttered model where everybody but you will be lost in details. Maybe the notification belongs to one level deeper, e.g. to "delivering items". Now, from an end to end perspective, "picking items" is a subprocess of order to cash. But from an organisational perspective, it's a process on its own that is performed at the warehouse. Picking can be related to orders, but also to sending obsolete articles to destruction. They are performed for many orders at the same time, etc. Maybe that some inventory is missing and the picking is set aside and only resumed later. So it is also a process on its own performed in the warehouse. For good modelling, you need to adopt a point of view. Personas can help (e.g. for the CEO, the end-to-end matter and means from customer to bank, but for the warehouse manager, only a group of related smaller processes matter; worse: the end to end could be understood differently, e.g. for a product entering into the warehouse until it exits).
However, avoid grouping (in a group or in a sequence), sub-processes-steps-tasks-operations that do not belong to the same level of abstraction. Just an extreme example: there's no value to group invoicing (top-level) and sending email (bottom level, also you could even go further to the clout or internet subscription). In other words, you may group 1.1, 1.2, 1.3 but not 1.1, 1.1.1, 1.1.1.2, ..... If it does, there's probably again something wrong in the decomposition.