From Abstract to Automated: Mastering BPMN Perspectives Through Incident Management

Introduction

Business Process Model and Notation (BPMN) is frequently misunderstood as a singular diagramming standard. In reality, BPMN is a multi-faceted modeling language capable of representing the same business process through varying lenses—ranging from high-level strategic overviews to granular technical execution specifications. The true power of BPMN lies not in creating one perfect diagram, but in selecting the appropriate perspective for the intended audience and purpose.

This guide examines the Incident Management process of a software manufacturer to illustrate this versatility. Based on Section 6 of the source material, we explore how a single scenario—a VIP customer reporting a product defect—can be modeled in three distinct phases. By progressing from abstract scoping to detailed collaboration and finally to system-driven automation, this case study demonstrates how BPMN facilitates alignment between business stakeholders and IT implementation teams.

---

Phase 1: High-Level Overview (Scoping and Abstraction)

The first phase of modeling serves to establish scope and ensure all stakeholders share a common understanding of the “happy path.” This view is intentionally simplified to avoid premature complexity.

The Scenario

A VIP customer reports a product problem to an account manager. The process follows a linear escalation chain:

1. The Account Manager attempts to resolve the issue.

2. If unresolved, it escalates to 1st Level Support.

3. 1st Level may escalate to 2nd Level Support.

4. 2nd Level may consult a Software Developer.

5. The solution flows back to the Account Manager, who explains it to the customer.

Key BPMN Concepts

• Single-Pool Modeling: This version utilizes a single pool containing multiple lanes. This approach effectively “blanks out” explicit communication protocols. It assumes participants communicate “somehow” without modeling the specific message flows, keeping the diagram clean and focused on sequence rather than interaction.

• Abstract Tasks: Tasks are deliberately left untyped (abstract). At this stage, there is insufficient information to determine whether a task is manual, automated, or a service call. Premature typing can constrain the design space; abstraction preserves flexibility during the scoping phase.

Primary Use Case: Stakeholder alignment, process scoping, and executive summaries.

---

Phase 2: Detailed Collaboration and Choreography

Once the high-level flow is agreed upon, the model evolves to capture the reality of human interaction and inter-departmental handoffs. This phase distinguishes between internal orchestration and external communication contracts.

The Scenario

Granular details are added to reflect actual operations. The dialogue between the Account Manager and the Customer is explicitly modeled to clarify problem definitions. Additionally, if a fix is not immediately possible, the 2nd Level Agent inserts a feature request into the Product Backlog, introducing a parallel workflow branch.

Key BPMN Concepts

• Collaboration Diagram (Multi-Pool): The model shifts from a single pool to multiple pools. This visualizes the “ping-pong-game” of messages between independent participants (Account Manager, Support Agents, Developers). Message flows now cross pool boundaries, making handoffs and dependencies explicit.

• Manual Tasks: Unlike Phase 1, tasks are now specifically typed as “Manual.” This indicates a completely human-driven process with no current automation, providing an accurate “As-Is” baseline.

• Choreography Diagram: This provides an alternative, communication-centric view. Choreography hides internal logic (such as updating a backlog or thinking time) and displays only the message exchanges between participants. It defines the contract of interaction rather than the internal processing.

  

• Shared Semantic Model: Crucially, the Collaboration and Choreography diagrams are not separate processes; they represent the exact same underlying semantic model viewed through different filters. Changes in one should logically reflect in the other.

Primary Use Case: Documenting human-to-human interactions, defining interface contracts, and analyzing communication bottlenecks.

---

Phase 3: Human-Driven vs. System-Driven Flows

The final phase bridges the gap between business process design and IT implementation. It identifies which elements remain human-centric and which can be orchestrated by a process engine, achieving true Business-IT Alignment.

The Scenario

To maximize efficiency, the process is hybridized. The Account Manager and Developer remain “human-driven,” communicating via email or face-to-face. However, the Support Agents’ workflows are now managed by a Trouble Ticket System, which acts as the central process engine.

Key BPMN Concepts

• Dedicated Process Engine Pool: The Trouble Ticket System is modeled in its own distinct pool. This explicitly shows the system’s role in parsing incoming emails, assigning User Tasks to agents, and making Service Calls to the Product Backlog API.

• Execution Details: This model moves beyond documentation to specification. It can be enriched with technical metadata (e.g., XML serialization schemas, API endpoints, variable mappings) required for a process engine to execute the workflow. Simpler, abstracted views of this same executable model can still be generated for business participants who do not need to see technical implementation details.

Primary Use Case: Technical specification for automation, process engine configuration, and defining the boundary between human and system responsibilities.

---

Summary of BPMN Perspectives in Incident Management

The following table synthesizes the key concepts across the three phases, serving as a quick reference for selecting the appropriate modeling approach.

BPMN Perspective	Primary Use Case	Key Notation/Element
High-Level	Scoping and basic flow understanding.	Single Pool, Lanes, Abstract Tasks.
Collaboration	Modeling human-to-human interaction / As-Is state.	Multi-Pools, Message Flows, Manual Tasks.
Choreography	Highlighting communication contracts between partners.	Choreography Tasks (showing two participants).
System-Driven	Technical specification for automation.	Service Tasks, Process Engine Pool, User Task assignments.

---

Conclusion

The Incident Management case study demonstrates that effective BPMN modeling is an exercise in perspective management. A single business process requires multiple representations to serve diverse needs: abstract models for scoping, collaborative models for understanding human interaction, choreography for defining contracts, and system-driven models for automation. Attempting to force all these concerns into a single diagram inevitably leads to either overwhelming complexity or dangerous oversimplification.

For practitioners looking to implement this multi-perspective approach, robust tooling is essential. Visual Paradigm is particularly well-suited for this methodology, as it supports the full spectrum of BPMN diagram types—from high-level orchestrations to executable choreographies—within a unified repository. Its ability to maintain a shared semantic model ensures that updates in the system-driven view automatically propagate to collaboration and choreography perspectives, preserving consistency across business and IT domains. By leveraging such tools alongside the phased modeling approach outlined in this guide, organizations can transform BPMN from a static documentation exercise into a dynamic bridge between business strategy and technical execution.