Process Modeling Levels: When Less Is More

One of the biggest challenges in business process modelling is defining the right level of detail. Models need to capture enough information to support analysis, optimization, and governance, without becoming overly complex or hard to maintain.

Organizations across industries often struggle with questions such as: Which activities should be modeled as separate tasks? When is it necessary to include events or data objects? And how detailed should a business process model really be for a specific use case?

This article explains how to determine the optimal process modelling level of detail, depending on your business objectives. You’ll learn how different modelling purposes require different abstraction levels and how a structured process model audit can help you continuously improve your process documentation.

Business processes have existed since the beginning of organized work. A business process is a structured set of activities designed to achieve a specific outcome, such as fulfilling a customer demand or delivering a product or service. As Davenport (1993) describes, processes define how work is carried out within an organization.

Business process modelling visualizes these activities and enriches them with information about responsibilities, resources, systems, timing, and quality criteria. However, the value of a process model does not depend on how much information it contains, but on whether it contains the right information.

This is where the level of detail becomes critical. A model that is too detailed quickly becomes complex and hard to maintain, while an overly abstract model may fail to support decision-making, analysis, or compliance requirements. Choosing the right level of detail is therefore a central success factor in business process modelling.

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

In practice, the required level of detail in process modelling strongly depends on whether a model is created for business or technical purposes. While both approaches often use the same notation standards, their objectives, and therefore their modelling depth, differ significantly.

In recent years, Business Process Model and Notation (BPMN 2.0) has become the accepted standard for process modelling. According to the BPMN specification, a task represents an atomic activity that is not further broken down into more detailed steps. This level of granularity is particularly suitable for technical process modelling, where processes are prepared for automation or execution by workflow engines.

Technical process modelling therefore, requires highly detailed and precise information, including system interactions, data structures, and execution logic. In this context, modelling activities as fine-grained, atomic tasks is both necessary and appropriate.

Business process modelling, however, follows a different logic. Its primary goal is not automation, but understanding, communication, analysis, and improvement of how work is performed. For these purposes, too much detail can reduce clarity and usability. A higher level of abstraction is often more effective, as it keeps models readable and easier to maintain while still supporting decision-making.

Understanding this distinction is essential when defining the right level of detail. Applying technical modelling principles to business process models often leads to unnecessary complexity, while overly abstract models can limit analytical value. The challenge lies in finding the right balance based on the intended use of the model.

The key question is not how detailed a process model can be, but how detailed it should be for a specific business purpose.

Determining the right level of detail in business process modelling depends primarily on the purpose of the model. Business process models are used for work instructions, analysis, optimization, compliance, risk management, and many other scenarios. Each of these use cases requires a different depth of information.

A common mistake is to model processes with the same level of detail regardless of their intended application. This often results in models that are either overly complex or too abstract to be useful. Instead, the level of detail should always be derived from clearly defined business requirements.

To achieve this, a structured approach is recommended. The optimal level of detail can be determined in two steps:

The business requirements of a process model can be summarized as an application scenario or use case. A single model may serve as a work instruction, support internal controls, enable risk assessments, guide process optimization initiatives, or act as a reference for audits and compliance checks.

When creating or revising a business process model, defining its primary use case should be the first step. The intended purpose determines which information must be included and which details can be omitted. This directly influences the appropriate level of detail.

Once the use case is clear, the next step is to decide how activities should be structured and separated. This includes determining when tasks should be split into smaller units and when they should remain aggregated.

For example, if a process model is used for process optimization, tasks must be detailed enough to distinguish between value-adding and non-value-adding activities. In contrast, if the model is used to identify risks and controls, a higher level of abstraction is often sufficient and more effective.

To support the decision on how much detail a process model should contain, BOC Group has developed a practical framework with four distinct levels of detail. This model helps organizations align their business process modelling efforts with concrete requirements by clearly defining how activities should be structured depending on the information needed.

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

Level 1 of modelling is used when the primary goal is to describe which roles are involved in a business process and how they interact to produce specific outcomes. The participants are documented using a RACI matrix (Responsible, Accountable, Consulted, Informed). Tasks typically represent the creation of individual business or technical results.

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

Level 2 is applied when it becomes necessary to specify more precisely which activities are performed by which roles, particularly for quantitative analysis or workload considerations. A new task is modeled whenever the responsible agent changes. This level may also reflect a change in the system used, such as a transition from manual to IT-supported processing.

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

Level 3 is used when it is important to show which activities are carried out and which intermediate results are produced. An activity is modeled as an uninterruptible unit of work that generates a defined intermediate outcome. This level of detail is particularly useful for understanding how work progresses step by step and where handovers, checks, or system interactions occur.

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

Level 4 is applied when a business process must be described in very high detail, typically for IT specifications or system implementations. Activities are modeled at the transaction or field level and often include the input or manipulation of technically related data within IT systems.

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

Each level of detail serves a specific purpose. Selecting the highest possible level of detail is rarely beneficial—instead, the chosen level should always reflect the intended use of the business process model.

As organizations mature in their process management practices, their process repositories often grow in size and complexity. Over time, this can lead to inconsistent levels of detail across models — some becoming overly detailed, others remaining too abstract to support analysis or decision-making.

A process model audit focused on the level of detail helps identify these inconsistencies and assess whether existing models are still fit for their intended purpose. Instead of reviewing models in isolation, this approach evaluates them against clearly defined application scenarios and modelling requirements.

Based on this assessment, gaps between the current state of process documentation and the required level of detail become visible. These insights make it possible to derive concrete, actionable recommendations, often small adjustments, that significantly improve the clarity, usability, and value of existing process models.

Process model audit procedure carried out by BOC Group. 

With more than 25 years of experience in Business Process Management, BOC Group supports organizations in reviewing and refining their process documentation to ensure that modelling efforts remain purpose-driven and sustainable over time.

Choosing the right level of detail in business process modelling is essential for creating process models that are useful, maintainable, and fit for purpose. Models should include enough information to support their intended use, without becoming overly complex.

The appropriate level of detail depends on the use case of the process model, such as process optimization, risk and control management, compliance, or IT implementation. It defines how activities are structured and when tasks should be combined or split.

Four distinct levels of detail help guide this decision, from high-level role-based views to detailed transaction-level descriptions. Selecting the right level ensures that process documentation delivers value while keeping modelling and maintenance efforts under control.

Sources:

Davenport, T. H. (1993). Process innovation: Reengineering work through information technology. Harvard Business School Press.

https://books.google.at/books/about/Process_Innovation