"We want to automate our process."
"Great, how does your process work?"
"Well... it depends."
This conversation happens constantly. Before you can automate or build software for a process, you need to understand what the process actually is.
Why Process Documentation Matters
You Can't Build What You Can't Define
Software needs clear rules. "It depends" doesn't compile.
Undocumented processes lead to:
- Software that doesn't fit reality
- Endless change requests
- Frustrated users
- Failed projects
You Don't Know What You Don't Know
The people doing the work often don't realize how much tacit knowledge they have. Documentation forces it out.
Processes Vary More Than You Think
Person A does it one way. Person B does it differently. Both think they're doing it "the right way."
Documentation reveals the variations.
Documentation Is Analysis
The act of documenting often reveals problems, inefficiencies, and opportunities you didn't see.
How to Document a Process
Step 1: Identify the Process Boundary
Where does this process start and end?
- Trigger: What causes this process to begin?
- Output: What does this process produce?
- Handoffs: Where does input come from? Where does output go?
Step 2: Observe, Don't Assume
Watch people actually doing the work. Don't just ask — observe.
What they say they do vs. what they actually do often differs.
Step 3: Map the Happy Path
Document the normal case first:
- Step 1: What happens
- Step 2: What happens next
- Continue through completion
Don't worry about exceptions yet.
Step 4: Identify Decision Points
Where does the process branch?
- If X, then Y
- If A, then B or C?
Document what determines each path.
Step 5: Document Exceptions
Now capture the edge cases:
- What happens when data is missing?
- What happens when there's an error?
- What happens when someone's unavailable?
- What happens with unusual requests?
Exceptions often outnumber the happy path.
Step 6: Capture Data and Systems
For each step:
- What data is needed?
- Where does it come from?
- What systems are used?
- What data is created or modified?
Step 7: Note Pain Points
While documenting, capture:
- What takes too long?
- What causes errors?
- What frustrates people?
- What workarounds exist?
Step 8: Validate
Review with multiple people who do the process:
- Is this accurate?
- What's missing?
- What's different in your area?
Documentation Formats
Simple: Numbered Steps
1. Receive order via email
2. Check inventory in ERP
3. If in stock, proceed to step 4. If not, notify customer (step 7)
4. Create pick list in warehouse system
...
Good for simple, linear processes.
Visual: Flowcharts
Boxes and arrows showing flow, decisions, and paths.
Good for complex processes with many branches.
Detailed: SIPOC
For each process:
- Suppliers: Who provides inputs?
- Inputs: What goes in?
- Process: High-level steps
- Outputs: What comes out?
- Customers: Who receives outputs?
Good for understanding context and boundaries.
Comprehensive: Procedure Documents
Full detail for each step:
- Who performs it
- What triggers it
- Detailed instructions
- Systems used
- Expected outcomes
- Exception handling
Good for training and compliance.
Common Documentation Mistakes
Too High-Level
"Process orders" isn't documentation. What does that actually mean?
Documenting the Ideal
Documenting how it should work, not how it actually works. Reality matters more.
Ignoring Exceptions
The happy path is 20% of the work. Exceptions are 80%.
One Person's View
Different people do it differently. Document the variations.
Set and Forget
Processes change. Documentation becomes outdated. Plan for maintenance.
From Documentation to Automation
With good documentation, you can:
Identify Automation Candidates
- Which steps are repetitive?
- Which decisions are rule-based?
- Where do errors occur?
- What takes the most time?
Define Requirements
- Clear inputs and outputs
- Decision logic documented
- Exception handling defined
- Integration points identified
Estimate Accurately
Documented process = known complexity = better estimates
Build the Right Thing
No ambiguity about what the system should do.
Test Effectively
Documentation provides test cases:
- Happy path
- Each decision branch
- Each exception scenario
Getting Started
Pick One Process
Don't try to document everything. Start with one process that:
- Causes pain
- Runs frequently
- Is a good automation candidate
Spend Time Observing
Sit with the people who do the work. Watch. Ask questions.
Draft, Review, Iterate
Your first version will be wrong. That's fine. Review with practitioners, revise, repeat.
Keep It Living
Documentation is only valuable if it's current. Build maintenance into the workflow.
Ready to document your processes for automation? Let's start mapping