Planning Bpmn Modeling

BPMN Modeling

Purpose

Design, document, and analyze business processes using BPMN 2.0 standards for process improvement and automation. Covers process discovery from stakeholders, AS-IS and TO-BE modeling across all process levels, applying BPMN patterns correctly, mapping BPMN to workflow automation engines, and designing DMN decision tables for automated decisions.

Agent Protocol

Trigger

"BPMN", "business process model", "process diagram", "process flow", "process modeling", "BPMN 2.0", "AS-IS process", "TO-BE process", "process discovery", "process automation", "Camunda", "DMN", "decision table", "process simulation", "workflow automation", "process mapping", "process design".

Input Context

• Process scope: start trigger, end outcome, boundaries (what's in/out)
• Current process description or existing diagram
• Pain points: delays, errors, handoffs, exceptions, bottlenecks
• Automation goals: cost reduction, throughput, compliance, visibility
• Stakeholders: process owner, participants, downstream consumers
• Technology constraints: target automation platform, existing systems
• Regulatory or compliance requirements for process design

Output Artifact

BPMN process model in BPMN 2.0 XML notation with DMN decision table definitions, swimlane mapping, and automation recommendations.

Response Format

## Process Model
Process Name: {name}
Level: {L1-L5}
Scope: {triggers} → {outcomes}
Owner: {role}

## BPMN Diagram Description
{pools/lanes and their responsibilities}
{flow with gateways, events, activities described textually}

## DMN Decision Table
Decision: {name}
Rules: {table with inputs/outputs}

## Automation Recommendation
Engine: {Camunda/Flowable/Temporal}
Implementation: {key implementation notes}

No preamble. No postamble. No explanations.

Completion Criteria

• Process scope and boundaries defined
• AS-IS process documented with all stakeholders
• TO-BE process modeled with automation opportunities
• BPMN diagram described textually (start/end events, activities, gateways, flows)
• Swimlanes mapped to roles or systems
• DMN decision tables defined for automated decisions
• Automation platform recommendation with rationale
• Implementation considerations documented

Max Response Length

7000 tokens

Decision Trees

Process Modeling Level Decision Tree

What is the audience for this process model?
  |-- Executive / Sponsors --> Level 1 (Contextual)
  |     Output: value chain, process relationships, 5-10 boxes
  |-- Process Owner / Manager --> Level 2 (Process Flow)
  |     Output: end-to-end flow, major steps, handoffs
  |-- Process Participants --> Level 3 (Detailed)
  |     Output: swimlanes, decisions, exceptions, 15-30 activities
  |-- Implementation Team --> Is automation planned?
  |     |-- YES --> Level 4 (Executable)
  |     |     Output: service tasks, business rules, message flows
  |     |-- NO --> Level 3 is sufficient
  |-- Developers / Integrators --> Level 5 (Technical)
        Output: implementation details, data mappings, API specs

AS-IS vs TO-BE Strategy

Process exists and is documented?
  |-- YES --> Is the process performing well?
  |     |-- YES --> Minor optimization, focus on automation
  |     |-- NO --> Full AS-IS analysis, identify pain points
  |           Output: pain point catalog with metrics
  |-- NO --> Do stakeholders agree on how the process works?
        |-- YES --> Jump to TO-BE design
        |-- NO --> Discovery session needed first

BPMN 2.0 Element Reference

Flow Objects

Connecting Objects

Swimlanes

Artifacts

Gateway Patterns

Exclusive Gateway (XOR)

           [Check Payment]
          /       |       \
    [Credit]   [Invoice]   [PO]
          \       |       /
           [Fulfill Order]

Only one path is taken. The decision is explicit — each outgoing flow has a condition.

Parallel Gateway (AND)

          [Approve Order]
          /             \
    [Pick Items]    [Process Payment]
          \             /
          [Ship Order]

All paths execute concurrently. Process waits at the merge until all paths complete.

Inclusive Gateway (OR)

          [Review Order]
          /           \
    [Check Credit]  [Check Fraud]
       (if new)       (if large)
          \           /
         [Process Order]

One or more paths execute depending on conditions. The merge waits for all activated paths.

Event-Based Gateway

          [Ship Order]
               |
        [Wait for Delivery]
        /       |       \
  [Delivered] [Damaged] [30-Day Timeout]

Process takes the first path whose event fires. Used for timeouts, external triggers, and competing scenarios.

BPMN Process Levels

Process Discovery Methods

Stakeholder Interview Guide

Pain Point Quantification Template

| Pain Point | Frequency | Impact | Current Workaround | Root Cause |
|------------|-----------|--------|-------------------|------------|
| Manual data entry errors | 15/week | 2hr rework each | Double-checking | No integration |
| Approval delays | 3/week | 24hr avg delay | Escalation email | No SLA tracking |

DMN Decision Table Design

Decision Table Structure

Decision: Approve Loan
Hit Policy: UNIQUE (only one rule matches)

| Credit Score | Income > $50K | Employment | Decision | Reason |
|--------------|---------------|------------|----------|--------|
| > 700        | YES           | > 2 years  | Approve  | Low risk |
| 600-700      | YES           | > 2 years  | Review   | Medium risk |
| < 600        | —             | —          | Reject   | High risk |
| —            | NO            | —          | Reject   | Insufficient income |

Hit Policies

Common Anti-Patterns

1. Modeling at Wrong Level

Showing technical implementation details to business stakeholders (L5 diagram for L1 audience). Fix: match level to audience. Create separate views for different stakeholders.

2. Unbalanced Gateways

Opening with a parallel gateway but closing with an exclusive gateway. Fix: every split must have a corresponding merge of the same type.

3. Magic Wand Automation

Modeling automation for activities that require human judgment, unstructured data, or subjective decisions. Fix: DMN tables only work for deterministic rules. If a decision requires judgment, it's a user task.

4. Happy Path Only Modeling

Showing only the ideal flow with no exception paths. Fix: every gateway should have a default flow. Every service task should have error boundary events.

5. One Giant Diagram

Putting an entire enterprise process on a single diagram. Overwhelming and unreadable. Fix: use subprocesses to decompose. Max 20 activities per diagram.

6. Mixing Pools and Lanes Incorrectly

Using lanes for systems within a company pool when they should be separate pools with message flows. Fix: separate pools for autonomous participants. Lanes for departments within the same organization.

7. No Start or End Events

Processes that start in the middle or never terminate. Fix: every process must have exactly one start event and one or more end events.

8. Over-Complex Gateway Logic

Chaining 5+ exclusive gateways in sequence makes the diagram unreadable. Fix: extract complex decision logic into DMN tables. Use business rule tasks instead of gateways.

Automation Platform Comparison

BPMN to Automation Mapping

Task Type Selection

Map each BPMN activity to the correct automation implementation type:

Error Handling Patterns

For each automated task, define error handling:

Process Mining Integration

Mining vs Modeling

Process mining discovers actual process flows from event log data, while BPMN modeling designs intended flows. Use process mining to validate BPMN models against reality:

Conformance Checking

Compare mined process against BPMN model to identify deviations. Calculate fitness score: how much of the mined process fits the model (0-1). Calculate precision: how much of the model is actually observed in data (0-1). Calculate generalization: how well the model explains unseen behavior. Targets: fitness >0.8, precision >0.7, generalization >0.8.

Process Enhancement

Use mining insights to enhance BPMN models: discovered bottlenecks (where does the process actually slow down?), actual path frequencies (which paths are most/least used?), exception patterns (what deviations recur?), resource utilization (which lanes are overloaded?), cycle time distribution (min/avg/max/P90 per activity).

Mining-Driven Automation Prioritization

Rank automation candidates by mining data: frequency (how often does this activity occur?), duration (how much time is spent on it?), variability (is it standardized or ad-hoc?), error rate (how often does it fail?). Target high-frequency, high-duration, low-variability activities first — these have the highest automation ROI and lowest implementation risk.

DMN Decision Table Design

Decision Table Structure

Decision: Approve Loan
Hit Policy: UNIQUE (only one rule matches)

| Credit Score | Income > $50K | Employment | Decision | Reason |
|--------------|---------------|------------|----------|--------|
| > 700        | YES           | > 2 years  | Approve  | Low risk |
| 600-700      | YES           | > 2 years  | Review   | Medium risk |
| < 600        | —             | —          | Reject   | High risk |
| —            | NO            | —          | Reject   | Insufficient income |

Hit Policies

Success Metrics

Rules

• Start with AS-IS modeling before designing TO-BE — skipping current-state analysis produces unrealistic designs
• BPMN models must be understandable by business stakeholders, not just developers
• Each swimlane represents one actor (role, system, external entity) — avoid mixing multiple actors in one lane
• Gateways must be balanced: every split must have a corresponding merge
• Exception paths must be modeled explicitly — catch-all flows hide process failures
• DMN hit policy must be explicit and correct for the business logic
• Service tasks should be idempotent — process engines may retry failed service calls
• Subprocesses should be limited to 2 levels of nesting for readability
• Process models at Level 4+ should only be designed if automation is planned
• Every process must have exactly one start event and one or more end events
• Label every sequence flow leaving a gateway with the condition
• Use intermediate catch events for waiting states, not timer tasks
• Message flows only cross pool boundaries, never within a pool
• Event subprocesses for error handling at the process level
• Validate BPMN diagrams with process participants before publishing

Expanded Decision Trees

Process Automation Priority Decision Tree

Which processes should be automated first?
  Is the process high-volume (>100 executions/month)?
    |-- YES --> Is it deterministic (rules-based)?
    |     |-- YES --> Priority 1: Automate (high ROI, low risk)
    |     |-- NO --> Is the human judgment bounded by clear rules?
    |           |-- YES --> Priority 2: Automate with DMN + human review
    |           |-- NO --> Priority 3: Keep manual, optimize process
    |-- NO --> Is the process error-prone in current state?
          |-- YES --> Priority 2: Automate to reduce errors
          |-- NO --> Is the process slow (>2 days cycle)?
                |-- YES --> Priority 3: Automate for speed
                |-- NO --> Low priority: document and monitor

Error Handling Strategy Decision Tree

What type of error can occur at this task?
  |-- Transient (timeout, network glitch, rate limit)
  |     |-- YES --> Retry with exponential backoff (max 3 retries)
  |-- Business rule violation (validation failure, constraint)
  |     |-- YES --> Boundary error event → route to manual review
  |-- System unavailable (downstream dependency down)
  |     |-- YES --> Does an alternative service exist?
  |     |     |-- YES --> Circuit breaker, fallback to alternative
  |     |     |-- NO --> Defer with escalation + retry later
  |-- Data quality issue (missing fields, format error)
        |-- YES --> Escalation user task with error context

DMN Hit Policy Selection Decision Tree

Can multiple rules match the same input?
  |-- NO --> UNIQUE hit policy (one rule matches)
  |-- YES --> Do all matching rules produce the same output?
        |-- YES --> ANY hit policy (consistent classification)
        |-- NO --> What behavior do you need?
              |-- First rule by priority order → FIRST
              |-- Collect all matching outputs → COLLECT
              |-- Collect and sort results → OUTPUT ORDER
              |-- Sequential evaluation → RULE ORDER

Templates

AS-IS Process Discovery Template

# Process Discovery: {Process Name}

## Scope
- Start trigger: {event that initiates the process}
- End outcome: {what signals completion}
- In scope: {activities, decisions, roles included}
- Out of scope: {explicitly excluded boundaries}

## Current State Flow
{textual or table-based description of the current process}

## Pain Points
| # | Pain Point | Stage | Frequency | Impact | Current Workaround | Root Cause |
|---|------------|-------|-----------|--------|-------------------|------------|

## Metrics (Current State)
- Average cycle time: {time}
- Error rate: {%
- Rework rate: {%
- Handoff count: {number}
- Automation level: {manual / partially automated / fully automated}

Process Analysis Report Template

# Process Analysis: {Process Name}

## Executive Summary
{1-2 paragraph summary of findings and recommendations}

## AS-IS Process Overview
{level L2 or L3 diagram description + metrics}

## Pain Point Analysis
{top 5 pain points with quantification}

## Automation Opportunities
| Activity | Type | Automation Approach | ROI Estimate | Priority |
|----------|------|-------------------|-------------|----------|

## TO-BE Process Overview
{level L4 diagram description + expected metrics}

## Implementation Roadmap
| Phase | Activities | Timeline | Dependencies |
|-------|-----------|----------|-------------|

## DMN Decisions
{decisions identified with hit policies}

## Risk Assessment
{risks in the TO-BE design with mitigation}

Process Discovery Interview Script

Opening (2 min):
  "Walk me through your day when [process trigger] happens."
  "What is the first thing you do?"

Process Flow (15 min):
  "What happens next?"
  "Who else gets involved?"
  "What systems do you use at this step?"
  "What information do you need and where does it come from?"

Decisions (10 min):
  "What decisions do you make during this process?"
  "How do you decide between option A vs option B?"
  "What would make you change your decision?"

Pain Points (10 min):
  "What frustrates you about this process?"
  "What goes wrong and how often?"
  "What workaround have you developed?"

Automation (5 min):
  "If you could wave a magic wand, what would change?"
  "What repetitive tasks would you eliminate?"

Closing (3 min):
  "Who else should I talk to?"
  "Is there anything we missed?"

Expanded Process Patterns

Pattern: Escalation and SLA Management

Model escalation paths using boundary timer events on user tasks. When a task exceeds its SLA, trigger an escalation: notify supervisor, reassign task, or automatically approve/reject based on rules. Use multiple escalation levels with increasing severity. Document escalation matrix clearly: Level 1 (2hr → team lead), Level 2 (4hr → department manager), Level 3 (8hr → director).

Pattern: Parallel Approval Workflow

Use parallel gateway to send approval requests simultaneously to multiple approvers. Combine with inclusive gateway if not all approvals are required. Implement the "majority approval" pattern: N out of M approvers must approve. Use DMN to determine which approvals are needed based on request characteristics (amount, risk, department).

Pattern: Saga Compensation for Long-Running Transactions

When a process spans multiple systems, implement compensating transactions for rollback. Each service task must have a corresponding compensation handler. If the process fails at step N, trigger compensation for steps N-1 through 1 in reverse order. Use event subprocesses for compensation logic. Important: compensation handlers must be idempotent and logged.

Pattern: Case Management with BPMN

For processes that are ad-hoc and knowledge-worker driven (not sequential), use Case Management Model and Notation (CMMN) concepts within BPMN. Model milestones instead of sequential steps. Allow workers to choose the order of tasks. Use event subprocesses for unplanned work. Plan items can be discretionary — available but not required.

Expanded Anti-Patterns

9. Process Over-Engineering

Modeling every possible variation and exception path on a single diagram. The diagram becomes unreadable and impossible to maintain. Fix: use subprocesses aggressively. Keep each diagram to max 20 activities. Model exception paths in separate subprocesses or event subprocesses.

10. Ignoring Non-Functional Requirements

Designing the process flow without considering performance, security, or compliance requirements. The automated process may work functionally but fail under load, expose data, or violate regulations. Fix: document non-functional requirements alongside the BPMN model. Add performance targets to service tasks. Include security and compliance review in model validation.

11. Manual-First Modeling

Designing the TO-BE process by simply automating the AS-IS process without rethinking the flow. You automate inefficiency. Fix: after documenting AS-IS, step back and redesign the process from scratch. Remove unnecessary steps. Change the order. Eliminate handoffs. Then add automation.

12. Missing Process Governance

No ownership, no monitoring, no version control for process models. BPMN diagrams become outdated within weeks. Nobody knows which version is deployed. Fix: assign a process owner for each major process. Store BPMN files in version control. Define a review cadence. Link process metrics to dashboards.

13. Data Flow Neglect

Modeling activity flow without specifying data flow. Service tasks have no defined inputs or outputs. The process works in theory but breaks in practice because data isn't available when needed. Fix: add data objects and data stores to every diagram. Define data mapping for each service task. Validate data flow end-to-end before implementation.

Process Simulation Guidance

When to Simulate

Run process simulation when: estimating capacity needs, evaluating "what-if" scenarios, validating TO-BE design before implementation, identifying bottlenecks and resource constraints, or building a business case for automation investment.

Simulation Parameters

Simulation Output Analysis

BPMN Collaboration Patterns

Partner Communication

Use message flows between pools to model B2B or B2C communication. Each pool represents an independent participant with its own process. Never use sequence flows across pool boundaries — only message flows. Document the message contract (payload schema, protocol, SLA) for each message flow.

Event-Based Collaboration

Use start message events and intermediate message events to model event-driven communication between participants. One participant's end event triggers another participant's start event via message. Use correlation keys to match related messages across processes. This pattern is essential for microservice orchestration.

Shared Data Visibility

Use data stores visible to multiple pools when participants share data. Define read/write permissions per pool. Use data associations to show which data is read or written by each activity. This pattern helps identify data ownership and access control requirements before implementation.

References

• references/bpmn-elements.md — BPMN 2.0 Elements
• references/bpmn-patterns.md — BPMN Patterns
• references/process-automation.md — Process Automation
• references/process-modeling.md — Process Modeling
• references/bpmn-modeling-advanced.md — Bpmn Modeling Advanced Topics
• references/bpmn-modeling-fundamentals.md — Bpmn Modeling Fundamentals
• references/dmn-decision-tables.md — DMN Decision Tables
• references/process-discovery-guide.md — Process Discovery Guide
• references/bpmn-automation-patterns.md — BPMN to Automation Patterns

Handoff

create-tech-spec for automation implementation specifications. solution-architecture for integration architecture design. create-story for breaking automation into user stories.