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)

• Transportation — moving information unnecessarily
• Inventory — work items waiting in queues
• Motion — people navigating between systems
• Waiting — idle time between steps
• Over-production — producing more than needed
• Over-processing — more steps than required
• Defects — 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