Process Mapper Skill

Systematic workflow for discovering, documenting, and analyzing processes. Implements user's SOP-first doctrine: "You can't automate what you can't see."

Core Philosophy

From user's work:

"When I sit with a person or team to start working through how they can work out where and how to apply AI into their job, I often like to start with a common task or value stream, and talk through—or more often than not, document—the SOP for that value stream."

Three truths:

Shadow processes are real processes (what actually happens ≠ org chart)
Tacit knowledge is documentable (capture decision points, not decision logic)
Structure enables automation (visibility → AI opportunities)

Core Workflow

1. Diagnostic: Assess Current State

Determine SOP state:

Load references/discovery-methodology.md for framework

State 1: Fiction

SOPs exist but nobody follows them
Beautiful docs, zero usage
Aspirational not actual

State 2: Nonexistent

No documentation
Tribal knowledge
"Just ask Sarah"

State 3: Accurate

Docs match reality
Referenced regularly
Updated when process changes

Action by state:

Fiction → Archive and start fresh
Nonexistent → Begin discovery (most common)
Accurate → Use for automation analysis

2. Process Discovery Interview

If starting from State 2 (Nonexistent), conduct discovery:

Setup:

Identify process owner (person who actually does this)
Secure 45-90 minutes uninterrupted
Frame: "Show me what actually happens, not what should happen"
Get screen access to tools they use

Five-round interview sequence:

Load references/discovery-methodology.md for detailed questions. Brief framework:

Round 1: High-Level Flow - Get end-to-end sequence (5-10 major steps, trigger, endpoint, duration)

Round 2: Step Decomposition - Break into substeps (inputs, tools, transformations). Look for copy-paste, manual entry, system switching.

Round 3: Decision Points - Identify where judgment is required. Distinguish explicit rules from tacit judgment (labeled black box pattern).

Round 4: Edge Cases & Exceptions - Understand failure modes, workarounds, frequency. High exceptions = process might be wrong.

Round 5: Context Dependencies - Identify tacit knowledge (domain knowledge, institutional knowledge, relationships). Reveals automation tractability.

3. Process Documentation

Choose format based on process characteristics:

Format 1: Linear SOP (≤10 steps, minimal branching)

Sequential steps with actions/tools/inputs
Quality checks
Common issues

Format 2: Decision Tree (multiple paths, branching logic)

Entry conditions
Path A/B/C with criteria
Decision matrix

Format 3: Swimlane (multi-role, handoffs important)

Who does what when
Handoff points
Role responsibilities

Format 4: Visual Diagram (complex flows)

Mermaid flowchart
System integrations
Exception paths

Load assets/visual-templates.md for specific templates

Documentation principles:

Capture actual current state (not aspirational)
Mark tacit knowledge points with ⚡
Note context dependencies with 🧠
Flag frequent failures with ⚠️
Include frequency/volume data
Validate with process owner

4. Complexity Classification

Map each process step to Tractability Grid (9 zones):

Load references/automation-framework.md for full framework and detailed assessment criteria.

Two dimensions:

Context Dependence: Low (algorithmic, no expertise) → High (tacit judgment, relationships)
Task Complexity: Simple (≤5 steps, single system) → Complex (15+ steps, multiple systems)

Assessment questions: Could intern do this with instructions? How many steps/systems/decisions?

5. Automation Opportunity Analysis

Plot each step on 9-zone grid (see references/automation-framework.md for visual):

Zones 1-2 (Green): High automation (85-75% success) - RPA, quick wins
Zones 3-5 (Yellow): Medium (60-40%) - AI copilots, human-in-loop
Zones 6-9 (Red): Low (<25%) - Avoid core automation, support tasks only

6. Prioritization & ROI

Priority quadrants (Pain × Feasibility):

P1 - Quick Wins: High pain, easy (Zones 1-2) - Do immediately
P2 - Strategic: High pain, hard (Zones 3-5) - Worth investment
P3 - Efficiency: Low pain, easy - Do when capacity available
P4 - Avoid: Low pain, hard (Zones 6-9) - Not worth effort

ROI: Payback Period = Cost / (Hours Saved × Rate + Error Reduction)

7. Output Delivery

Standard deliverables: Process Map (visual), SOP Document (written), Automation Analysis (zone classifications, priorities, ROI), Implementation Roadmap (phased plan)

Optional: Interview transcript, validation notes, comparative analysis, metrics dashboard

The Labeled Black Box Pattern

Critical technique: Document THAT a decision exists, not HOW it's made (when tacit).

Load references/documentation-patterns.md for detailed examples and template.

Core principle: Name decision points even when logic is tacit. Enables process visibility, appropriate handoffs, training focus, and future automation planning.

Movement Strategy

Key insight: Can't automate high-context zones directly. Build infrastructure to move problems to lower zones.

Load references/documentation-patterns.md for case study (Air India: Zone 8 → Zone 2, 97% accuracy).

Infrastructure path: Zone 8→5 (frameworks), Zone 5→2 (explicit logic), Zone 2→1 (eliminate manual steps)

Quality Signals

Good process map has:

Red flags:

Too neat (probably fictional)
No exceptions (incomplete)
No pain points (not real discovery)
No tacit knowledge points (missed shadow process)
Can't estimate frequency (no data)
Process owner says "that's not quite right"

Integration Points

With concept-forge:

Test automation hypotheses dialectically
Challenge zone classifications
Refine through multiple perspectives

With strategy-to-artifact:

Process map → Presentation deck
Automation roadmap → Executive one-pager
Business case → Slide deck

With research-to-essay:

Process patterns → Substack post on SOP doctrine
Case studies → Long-form analysis

With user's voice (from research-to-essay):

Use dialogue structure in documentation
Employ concrete examples (Air India vs Air Canada)
Include practitioner stance ("In my experience...")
Show recursive refinement ("Let me be more precise...")

Common Process Types

Approval Workflows: Zones 1-2 (rule-based) or 4-5 (judgment). High automation potential for rules.

Data Processing: Zones 1-3. Very high automation if algorithmic.

Customer Service: Zones 4-8. Medium automation (copilot model).

Reporting: Zones 1-3 (structured) or 5-7 (insights). High for gathering, medium for analysis.

Coordination: Zones 4-9 (relationship-dependent). Low for core, high for supporting tasks.

Anti-Patterns

Don't:

Map aspirational process (document what actually happens)
Skip validation with process owner (will be wrong)
Try to capture tacit HOW (use labeled black box)
Force Zone 8-9 into automation (will fail)
Ignore shadow processes (they're the real process)
Over-document (keep it actionable)
Create one-time map (processes evolve, keep updated)

Do:

Start with actual current state
Validate iteratively
Document decision points even when logic is tacit
Acknowledge complexity honestly
Focus on high-ROI opportunities
Build movement infrastructure
Update as process changes

Success Metrics

Process mapping succeeds when:

Process owner says "Yes, that's exactly what we do"
New team members can follow documented process
Automation opportunities clearly identified
ROI estimates are validated
Quick wins deliver promised value
Documentation is referenced regularly (not ignored)

Automation analysis succeeds when:

Zone classifications match reality
Prioritization aligns with business value
Implementation follows plan
Expected savings materialize
User adoption high (not forced)

Example Triggers

"Map our customer onboarding process"
"Document how we handle support tickets"
"Where can we apply AI to our workflow?"
"Create SOP for expense approval"
"Show me where automation makes sense"
"Why does this process keep breaking?"
"Help me understand what my team actually does"
"Walk me through your typical day"

process-mapper