Process Modeling

When to Use This Skill

Use this skill when:

Process Modeling tasks

- Working on process modeling using bpmn notation and flowchart patterns. creates process diagrams with activities, gateways, events, swimlanes, and decision points for workflow documentation

Planning or design

- Need guidance on Process Modeling approaches

Best practices

- Want to follow established patterns and standards

Overview

Create and document business processes using BPMN (Business Process Model and Notation) and flowchart notation. Visualize activities, decisions, events, and participant interactions for process understanding and improvement.

What is Process Modeling?

Process modeling

creates visual representations of how work flows through an organization. It documents:

Activities

What work is performed

Sequence

Order of activities

Decisions

Choice points and conditions

Participants

Who performs each step

Events

What triggers and ends the process BPMN Core Elements Activities (Rectangles) Type Symbol Description Task Rectangle Atomic work unit Sub-Process Rectangle with + Contains child process Call Activity Rectangle with thick border Invokes reusable process Task Types: Type Description User Task Human interaction required Service Task Automated system action Script Task Script/code execution Business Rule Task Decision table evaluation Send Task Message sent Receive Task Message received Manual Task Physical work without system Events (Circles) Position Symbol Description Start Thin circle Process trigger Intermediate Double circle Mid-process event End Thick circle Process termination Event Types: Type Trigger None Unspecified start/end Message Message received/sent Timer Time-based trigger Error Error condition Signal Broadcast signal Terminate Process termination Gateways (Diamonds) Type Symbol Description Exclusive (XOR) Diamond with X One path based on condition Parallel (AND) Diamond with + All paths execute Inclusive (OR) Diamond with O One or more paths Event-Based Diamond with circle Wait for events Connectors Type Symbol Description Sequence Flow Solid arrow Order of activities Message Flow Dashed arrow Messages between pools Association Dotted line Artifacts to elements Swimlanes Type Description Pool Represents a participant (organization/system) Lane Subdivisions within a pool (roles/departments) Workflow Phase 1: Define Scope Step 1: Identify Process Boundaries

Process Definition ** Process Name: ** [Name] ** Purpose: ** [Why this process exists] ** Scope: ** - ** Starts When: ** [Trigger event] - ** Ends When: ** [Completion criteria] - ** Includes: ** [In-scope activities] - ** Excludes: ** [Out-of-scope activities] ** Participants: ** | Pool | Lanes (Roles) | |

|

| | [Org/System] | [Role 1], [Role 2] | Step 2: Choose Model Type Type When to Use As-Is Documenting current state To-Be Designing future state High-Level Overview, communication Detailed Implementation, automation Phase 2: Model the Process Step 1: Identify Main Path (Happy Path) Start event (trigger) Main sequence of activities End event (completion) Step 2: Add Decision Points For each decision: Type of gateway (XOR/AND/OR) Conditions for each path Reconvergence point Step 3: Add Exception Paths Error handling Timeout scenarios Escalation paths Step 4: Add Participants Assign activities to lanes Model inter-participant communication Add message flows between pools Phase 3: Validate and Document Step 1: Validate Completeness Check Question All paths connected Do all activities have incoming and outgoing flows? No dead ends Do all paths reach an end event? Gateways balanced Are split gateways matched with joins? Roles assigned Is every activity in a lane? Triggers defined Does every start event have a clear trigger? Step 2: Add Documentation

Process: [Name]

Overview [Brief description of process purpose and flow]

Triggers | Event | Description | Frequency | |

|

|

| | [Trigger] | [What causes it] | [How often] |

Activities |

| Activity | Role | System | Duration | |

|

|

|

|

| | 1 | [Activity name] | [Role] | [System] | [Time] |

Decision Points |

| Decision | Conditions | Paths | |

|

|

|

| | 1 | [Decision] | [Criteria] | [Path A], [Path B] |

Exceptions | Exception | Handling | |

|

| | [Error] | [How handled] | Output Formats Mermaid Flowchart (BPMN-Style) flowchart TD Start ((Start)) Task1 [Receive Order] Gateway1 {Valid Order?} Task2 [Process Payment] Task3 [Reject Order] Task4 [Ship Product] End1 ((Complete)) End2 ((Rejected)) Start --> Task1 Task1 --> Gateway1 Gateway1 --> |Yes| Task2 Gateway1 --> |No| Task3 Task2 --> Task4 Task4 --> End1 Task3 --> End2 Swimlane Diagram flowchart TD subgraph Customer A [Place Order] G [Receive Product] end subgraph Sales B [Review Order] C {Approved?} end subgraph Warehouse D [Pick Items] E [Pack Order] F [Ship Order] end A --> B B --> C C --> |Yes| D C --> |No| A D --> E E --> F F --> G Narrative Summary

Process: Order Fulfillment ** Version: ** 1.0 ** Date: ** [ISO Date] ** Owner: ** [Name]

Summary This process handles customer orders from receipt to delivery.

Flow Description

1.

**

Start

**

Customer places order (online or phone)

2.

**

Review Order

**

Sales validates order details

3.

**

Decision

**

Is order valid?

Yes: Proceed to fulfillment

No: Return to customer for correction

4.

**

Pick Items

**

Warehouse locates products

5.

**

Pack Order

**

Items packaged for shipping

6.

**

Ship Order

**

Handed to carrier

7.

**

End

**

Customer receives product

Metrics | Metric | Current | Target | |

|

|

| | Cycle Time | 3 days | 2 days | | Error Rate | 5% | 1% | | Automation | 40% | 70% |

Improvement Opportunities 1. Automate order validation 2. Parallel picking for multi-item orders 3. Real-time tracking integration Structured Data (YAML) process_model : name : "Order Fulfillment" version : "1.0" date : "2025-01-15" type : "as_is"

or "to_be"

owner : "Operations" boundaries : trigger : "Customer places order" end_state : "Customer receives product" scope : includes : - "Order receipt" - "Payment processing" - "Fulfillment" - "Shipping" excludes : - "Returns" - "Customer support" participants : - pool : "Company" lanes : - name : "Sales" activities : [ "Review Order" ] - name : "Warehouse" activities : [ "Pick Items" , "Pack Order" , "Ship Order" ] - pool : "Customer" lanes : - name : "Buyer" activities : [ "Place Order" , "Receive Product" ] elements : events : - id : "start_1" type : "start" name : "Order Received" trigger : "message" - id : "end_1" type : "end" name : "Order Complete" activities : - id : "task_1" type : "user_task" name : "Review Order" lane : "Sales" duration : "15 minutes" - id : "task_2" type : "service_task" name : "Process Payment" lane : "Sales" system : "Payment Gateway" gateways : - id : "gw_1" type : "exclusive" name : "Order Valid?" conditions : - path : "task_2" condition : "Order validated" - path : "task_reject" condition : "Validation failed" sequence_flows : - from : "start_1" to : "task_1" - from : "task_1" to : "gw_1" - from : "gw_1" to : "task_2" condition : "valid" metrics : cycle_time : current : "3 days" target : "2 days" automation_rate : current : 40 target : 70 Common Process Patterns Sequential Process Activities in strict order, one after another. flowchart LR A [Step 1] --> B [Step 2] --> C [Step 3] --> D [Step 4] Parallel Split and Join Activities that can occur simultaneously. flowchart TD A [Start] --> B {Parallel Split} B --> C [Task A] B --> D [Task B] B --> E [Task C] C --> F {Join} D --> F E --> F F --> G [End] Exclusive Decision Only one path taken based on condition. flowchart TD A [Review] --> B {Decision} B --> |Approve| C [Process] B --> |Reject| D [Notify] C --> E [End] D --> E Loop/Iteration Repeat activities until condition met. flowchart TD A [Start] --> B [Process] B --> C {Complete?} C --> |No| B C --> |Yes| D [End] Exception Handling Handle errors and exceptions. flowchart TD A [Process] --> B {Success?} B --> |Yes| C [Continue] B --> |Error| D [Handle Error] D --> E {Recoverable?} E --> |Yes| A E --> |No| F [Escalate] Best Practices Practice Description Start simple Begin with happy path, add complexity One start, one end Per pool, ideally Name activities Use verb-noun format (e.g., "Review Order") Label gateways Show the decision question Label conditions Describe each outgoing path Balance gateways Split and join with matching types Avoid crossing lines Rearrange for clarity Document exceptions Show error handling paths Integration Upstream stakeholder-analysis - Process participants domain-storytelling - Current process discovery capability-mapping - Capability context Downstream value-stream-mapping - Value flow analysis Requirements - Process requirements System design - Automation opportunities