# Process Design

> When to activate: business process mapping, BPMN diagrams, swimlane flows, SLA design, bottleneck identification, process automation, workflow documentation, SOPs

- Skill: `mattakushi432/process-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mattakushi432/process-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mattakushi432/process-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Mattakushi432 (https://skillmd.com/u/mattakushi432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mattakushi432/process-design

---


# Business Process Design

## Process Discovery Framework

### Step 1 — Define Scope
- Start point: what triggers the process?
- End point: what is the final deliverable or state?
- Owners: who is accountable for the end-to-end outcome?
- Stakeholders: who participates or is affected?
- Frequency: how often does this run? (per transaction / daily / weekly)

### Step 2 — As-Is Mapping (Current State)
1. Interview process owners and frontline operators separately
2. Shadow the process live — don't rely on documentation alone
3. Capture every handoff: where work moves between people or systems
4. Note informal fixes, workarounds, and shadow tools
5. Record timing for each step (optimistic / typical / worst case)

### Step 3 — Bottleneck Analysis
| Signal | Likely bottleneck |
|--------|------------------|
| Work piles up before a step | Capacity constraint at that step |
| Long wait times between steps | Approval dependency or unclear ownership |
| High rework rates | Ambiguous inputs or missing specifications |
| Frequent escalations | Decision authority not delegated low enough |
| Duplicate work across teams | Missing single source of truth |

### Step 4 — To-Be Design
- Remove: steps that add no value from the customer perspective
- Automate: repetitive, rule-based steps with structured inputs
- Simplify: steps that require judgment but could be standardized
- Parallel: steps currently sequential that have no true dependency
- Delegate: decisions pushed too high that could be made at execution level

---

## BPMN Notation Quick Reference

### Core Symbols
| Symbol | Name | Use |
|--------|------|-----|
| Circle (thin) | Start Event | Process begins |
| Circle (thick) | End Event | Process ends |
| Rounded rectangle | Task | Work performed by an actor |
| Diamond | Gateway | Decision or fork point |
| Rectangle with lines | Sub-Process | Collapsed complex process |
| Dashed arrow | Message Flow | Communication between pools |
| Solid arrow | Sequence Flow | Task ordering |

### Gateway Types
- **Exclusive (X)** — one path taken, based on condition
- **Parallel (+)** — all paths taken simultaneously
- **Inclusive (O)** — one or more paths based on condition

### Swimlane Structure
```
Pool: [Company]
  Lane: [Sales]        → owns deal qualification, proposal
  Lane: [Legal]        → owns contract review, redlines
  Lane: [Finance]      → owns deal desk approval, invoicing
  Lane: [Customer]     → external participant (dashed pool)
```

---

## SLA Design

### SLA Template
```
Process: [Name]
SLA Owner: [Role]
Measurement period: [daily / weekly / monthly]

Tier 1 — Standard:
  Target: respond within 4 business hours
  Resolution: within 2 business days
  Applies to: [low-priority tickets / routine requests]

Tier 2 — Priority:
  Target: respond within 1 business hour
  Resolution: within 4 business hours
  Applies to: [high-value accounts / escalations]

Tier 3 — Critical:
  Target: respond within 15 minutes
  Resolution: within 2 hours
  Applies to: [production outages / revenue-blocking issues]
```

### SLA Metrics
| Metric | Formula | Target |
|--------|---------|--------|
| SLA Attainment | # tickets resolved within SLA / total tickets | ≥ 95% |
| MTTR (Mean Time to Resolve) | Total resolution time / # tickets | Per tier target |
| Breach Rate | # SLA breaches / total tickets | < 5% |
| Escalation Rate | # escalated / total tickets | < 10% |

---

## Automation Opportunity Assessment

### Automation Readiness Checklist
- [ ] Input is structured or can be made structured
- [ ] Rules for processing are explicit and documented
- [ ] Exceptions are predictable and < 15% of volume
- [ ] Process runs frequently enough to justify build cost
- [ ] Regulatory requirements allow automation
- [ ] Rollback plan exists if automation fails

### Automation ROI Formula
```
Annual manual cost = (avg minutes per case / 60) × hourly rate × annual volume
Automation cost = build cost + annual maintenance
Break-even = automation cost / (annual manual cost - automation run cost)
```

### Priority Matrix
| Frequency | Manual effort | Automation priority |
|-----------|--------------|-------------------|
| High | High | P0 — automate immediately |
| High | Low | P2 — consider if low build cost |
| Low | High | P1 — automate or outsource |
| Low | Low | P3 — leave manual |

---

## Process Documentation Standard

### SOP Structure
```
Title: [Process Name]
Version: 1.x
Owner: [Role]
Last reviewed: [YYYY-MM-DD]
Next review: [YYYY-MM-DD]

1. Purpose
   One sentence: what does this process accomplish?

2. Scope
   Who does this apply to? What is included / excluded?

3. Inputs
   List required inputs, formats, and source systems.

4. Steps
   Step 1: [Action] → [Actor] → [Output/Artifact]
   Step 2: ...

5. Decision points
   If [condition] → go to step X
   If [condition] → escalate to [Role]

6. Outputs
   List deliverables, where they are stored, who receives them.

7. Exceptions
   Document known edge cases and handling procedures.

8. Related documents
   Link to: upstream processes, downstream processes, policy docs.
```

### Document Control
- Store in single authoritative location (wiki, Notion, Confluence)
- Assign a process owner responsible for quarterly review
- Version with date + author in header
- Archive superseded versions — don't delete

---

## Process Improvement Methodologies

### Lean — Waste Categories (TIMWOOD)
- **T**ransportation — moving information unnecessarily
- **I**nventory — work items waiting in queues
- **M**otion — people navigating between systems
- **W**aiting — idle time between steps
- **O**ver-production — producing more than needed
- **O**ver-processing — more steps than required
- **D**efects — errors requiring rework

### Six Sigma DMAIC
1. **Define** — charter, SIPOC, voice of customer
2. **Measure** — baseline current performance, collect data
3. **Analyze** — root cause analysis (fishbone, 5-why)
4. **Improve** — pilot improvements, validate with data
5. **Control** — standardize, hand off with monitoring plan

### Kaizen Event Structure (5-day)
| Day | Activity |
|-----|----------|
| 1 | Current state mapping, problem definition |
| 2 | Root cause analysis, solution brainstorm |
| 3 | Pilot and test solutions |
| 4 | Implement and document |
| 5 | Report out, set 30-day follow-up actions |

---

## Governance

### Process Review Cadence
| Process type | Review frequency |
|-------------|-----------------|
| Customer-facing | Quarterly |
| Regulatory / compliance | Annually (or when regulation changes) |
| Internal operational | Semi-annually |
| Incident-driven | After every major incident |

### Change Control
1. Submit process change request with: what, why, impact assessment
2. Review by process owner + key stakeholders
3. Pilot on limited scope before full rollout
4. Update documentation before go-live
5. Communicate to all affected parties
6. Monitor for 30 days post-change