Summary: Before automating a process, map what actually happens—not only what the procedure says should happen. A simple map of triggers, steps, decisions, handovers, information and exceptions is usually enough to expose the real improvement opportunities.
Why map before automating?
Automation makes a defined process faster and more consistent. If ownership, rules or information are unclear, automation can make confusion travel faster. Mapping creates a shared view that teams can challenge before software decisions become expensive.
A simple six-part method
- Define the outcome. State what successful completion means.
- Name the trigger. Identify the event that starts the process.
- List the real steps. Follow actual work, including spreadsheets, email and chat.
- Mark decisions and exceptions. Record approval rules, missing information and rework.
- Identify owners and handovers. Show who is responsible at every stage.
- Record information and systems. Note what is created, changed or consulted.
Example: supplier approval
A request starts when a user proposes a new supplier. Procurement checks required details, Finance validates banking and tax information, a responsible manager approves the relationship, and only then may the supplier be used for purchasing.
The map should also ask: What happens when documents are missing? Who may change bank details later? Is reapproval required? Which evidence must be retained? Those exception rules often matter more than the happy path.
Use a practical mapping table
| Element | Question |
|---|---|
| Trigger | What starts the process? |
| Activity | What work is performed? |
| Owner | Who is accountable? |
| Decision | Which rule changes the route? |
| Information | What is needed or produced? |
| Exception | What can go wrong? |
| Measure | How do we know it works? |
Look for improvement opportunities
- Duplicate entry of the same information
- Waiting caused by unclear ownership
- Approvals with no defined threshold
- Manual checks that can use reliable rules
- Reports assembled instead of generated
- Exceptions with no controlled route
Do not automate every step
Remove unnecessary work first. Standardise what remains. Automate repeatable rules. Keep human judgment where context, accountability or risk requires it.
Define the future state
The future map should describe a realistic first release: required fields, roles, decisions, notifications, integrations, reports and exceptions. Use it to create acceptance scenarios before configuration or development begins.
Move from map to implementation
Répartiq combines process analysis with practical ERP, software and integration pathways.
Explore business analysis View the supplier approval demonstration
Related guidance
Editorial status: Draft — technical and brand review required before publication. The supplier example is synthetic and is not presented as a completed client implementation.