Process Mapper Leegonzales Aiskills 2

---
name: process-mapper
description: Map workflows, extract SOPs, and identify automation opportunities through systematic process capture and AI tractability assessment. Use when documenting workflows, creating SOPs, conducting process discovery interviews, or analyzing automation opportunities. Grounds the SOP-first doctrine in tacit knowledge documentation and structured analysis.
license: Complete terms in LICENSE.txt
---

# 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:**
1. **Shadow processes are real processes** (what actually happens ≠ org chart)
2. **Tacit knowledge is documentable** (capture decision *points*, not decision *logic*)
3. **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:**
1. **Context Dependence:** Low (algorithmic, no expertise) → High (tacit judgment, relationships)
2. **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:**
- [ ] Actual current state (not aspirational)
- [ ] All decision points identified
- [ ] Tacit knowledge points marked (⚡)
- [ ] Context dependencies noted (🧠)
- [ ] Exception paths included
- [ ] Validated by process owner
- [ ] Frequency/volume data
- [ ] Pain points documented
- [ ] Clear start and end
- [ ] Realistic time estimates

**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"