The approach to dealing with complexity has been “Divide et Impera” since the Roman Empire, which means breaking down a complex problem into smaller, more manageable pieces. 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. The solution is to take a step back, zoom out, and identify the essential components without getting sidetracked by implementation details.
1. Split Processes. Big picture will reveal that some sub-processes are not necessarily performed in sequence and are instead a set of interconnected dynamic processes. Presenting too many details too early might hide this fact, and give impression of a big monolithic process. This is why the borderline between process and process groups can be somewhat fuzzy, and often more a convention.
For example, in the order-to-cash process, it may be tempting to see it as 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).
2. Use Sub-Processes. BPMN allows you to use sub-processes to split a complex process into multiple levels, making it easier to understand and manage. A sub-process is a compound activity that represents a collection of other tasks and sub-processes.
Breaking it down into smaller Sub-Process Diagrams is necessary. Focusing on details too early will lead to a cluttered model where everyone except the modeller gets lost in the details. The picking process, for instance, is a subprocess of the order-to-cash process from an end-to-end perspective, but from an organizational perspective, it’s a process on its own that is performed at the warehouse. For good modelling, adopting a point of view is essential. Personas can help with this. For the CEO, the end-to-end means from customer to bank, but for the requirements engineer, only a group of related smaller processes matter. The “end to end” could be understood differently, e.g. for a product entering into the warehouse until it exits.
However, it is crucial to avoid grouping sub-processes-steps-tasks-operations that do not belong to the same level of abstraction. There is no value in grouping invoicing and sending email as they are not at the same level of abstraction. If they are grouped, it indicates that there is something wrong with the decomposition.
3. Another practice can be to Link Intermediate Events. If a process model extends beyond the length of one printed page, you can use Link Intermediate Events to show how Sequence Flow connections extend across page breaks. This allows you to visually represent how the process flows from one page to another.
It’s important to note that BPMN is a flexible notation, and the specific structure of a big process will depend on the unique requirements of the organization and the process itself. The above guidelines can serve as a starting point for structuring big processes in BPMN.