Business Process Modelling: The Optimal Level of Detail

Customers across all industries always ask for the right flight-level when it comes to modelling of business processes. The main challenge: encompassing all necessary details, while also documenting only the right information. This line of thinking often raises questions such as: Can I combine tasks? When do I need to add events? What input and output data should I model?

In this blog post, you will learn how to define and successfully achieve the optimal level of detail for your business process models and, on the other hand, how a process model audit can support you in further evolving your process management practice.

Processes have existed since the beginning of time, and humans have been intensively involved with processes for several centuries. A business process is a set of activities designed to achieve a specific outcome, for example, for a particular demand or market. Processes describe HOW work is done in an organisation (Davenport, 1993, p.5). Process modelling is the visualisation of these activities and is complemented with information about who performs the activity, how and with which resources, in which quality and when.

If you want to learn more about this, read our blog post about process documentation

In recent years, the modelling language Business Process Model and Notation (BPMN 2.0) has become the accepted standard for process modelling (ISO/IEC 19510:2013). Here, a distinction is made between technical and functional modelling.

When it comes to the level of detail in activities, the OMG BPMN 2.0 specification states it very clearly: “A task is an atomic activity included in a process. It’s used when the work in the process is not broken down to a finer level of detail.”

Technical modelling aims to automate a process, or the individual process steps, using a workflow engine. This naturally requires very specific and detailed information to be documented. Thus, for technical modelling purposes, the OMG principle of modelling detailed atomic tasks seems appropriate. However, for business process modelling, less information is often the better way to go.

Business process modelling is used for work instructions and various analytical purposes. The level of detail for this type of modelling should be based on the business requirements. This process involves decisions on how to “chop up” the activities, i.e. according to which criteria a new activity is to be modelled.

The correct level of detail of a process model can be determined in two steps.

The business requirements for a process model can be summarized as an application scenario or use case. For example, a single process model can be used as a work instruction for risk management, internal control system, process optimization, business continuity management, in process-based application development, or even as a template for certain audits.

When modelling a new process or its revision, it’s recommended to define the use case of this model as the first step. The purpose of the model determines the required level of detail, which in turn dictates the scope of information and artifacts that need to be modelled (see Figure 2).

To determine the level of detail, it’s important to consider which information is needed for the chosen, individual scenarios.

For example, if a business process model is to be used to optimize a process in which non-value-adding activities are eliminated, the individual tasks must be modelled in sufficient detail to be able to classify them as “value-adding” or “non-value-adding” accordingly.

If, on the other hand, the business process model is used to show where risks exist and controls are in place, a higher level of abstraction is sufficient enough.

To determine the right amount of detail in modelling, BOC Group has developed a model with four different levels of detail. Based on this, the appropriate level of detail is determined according to the required information.

Four Levels of Detail of Process Modelling (developed by BOC Group)

Level 1 of modelling is (only) used when you need to describe which parties are involved in a business process and how they interact in order to produce individual technical results. The participants are stored in the RACI matrix (Responsible, Accountable, Consulted, Informed) as information (role). A task usually describes the generation of individual technical results.

Examples: “Create and send offer”, “Plan production”, “Manufacture product”, “Deliver product” or “Create invoice”.

Level 2 is used for modelling when it’s necessary to specify more precisely which activities the individual roles carry out for quantitative consideration. Here, a new task is modelled when the agent changes. An additional factor is a change of the system, e.g. a change from paper processing to IT-supported processing.

Examples: “Accept customer enquiry”, “Create offer in SAP” or “Generate offer as PDF”.

Level 3 is used for modelling when you need to show which activities are carried out and which intermediate results are produced. An action is described as an uninterruptible activity that “produces” an intermediate technical result. From an IT perspective, activities often describe “memory points”.

Examples: “Accept customer enquiry”, “Open offer in SAP”, “Enter offer positions”, “Check offer” or “Generate offer as PDF”.

Level 4 is used for modelling when a business process is to be described in great detail, for example for IT specifications (new implementations). At this level, the activities that are carried out are shown at the “transaction level”. If the activities are IT-supported, these are often the input of technically-related data.

Examples: “Check incoming mail”, “Open mail”, “Classify mail”, “Forward mail to Sales”, “Identify customer” and “Generate quote number in SAP”.

If a process model is to be used for several scenarios that require different levels of detail, focus on the scenario with the most detailed requirements.

For each process model to serve its intended purpose in the best way possible (while keeping maintenance efforts to a minimum), modelling should be detailed, but only as specific as necessary. The level of detail of a model defines how tasks are “broken up”, i.e. according to which criteria a new activity is documented. The application scenario or the purpose of the model defines the requirements for the level of detail. Four different levels of detail help to decide when activities should be combined or split.

Your process management tool is filled with models and you’re looking to review and refine them? In this case, a process model audit is the right method to ensure that your processes are modelled efficiently and fulfil their purpose in the most effective way.

Our process experts are happy to support you in your process audit efforts! First, we show you which typical application scenarios exist, and determine together which of these are relevant for you and your company. Next, we select a model package with models relevant for this scenario repository. We then assess these models according to the level of detail needed, correct modelling standards, and consider the accompanying information.

Based on this evaluation, we indicate the gaps between the ACTUAL state of your process documentation and the TARGET requirements of your selected scenarios. These gaps are then presented by BOC consultants with concrete recommendations for further action. Often, even small adjustments can generate extra added-value from your process documentation. The figure below summarized this process and the outcome of a process model audit performed by BOC Group.

Process model audit procedure carried out by BOC Group. 

We’re happy to share our 25+ years of experience in Business Process Management with you! Get in touch with us to discuss process model audits in more detail, or if you’d like to get support in the purpose-oriented modelling of your business processes!

Click on the link below and share your thoughts with us – we will get back to you shortly!