01 / Trigger
A need is identified
Item, quantity, reason, and required date become a clear request.
Request ownerAn independent operations field guide
See the work.
Connect the dots.
Before you choose a system, understand the process. Practical notes for mapping the people, information, and decisions that keep a business moving.
Map your first processExample / A simple purchase request
From request to recorded receipt
02 / Decision
Approval is checked
The right person reviews the request against the agreed rules.
Approver03 / Handoff
An order is placed
Approved details become an order that a supplier can act on.
Purchasing04 / Evidence
Receipt is recorded
What arrived is compared with what was requested and ordered.
ReceivingIllustrative process only. Actual responsibilities and approval rules depend on the organization.
01 / Start with shared understanding
A process is more than a row of tasks.
The useful details live between the boxes: who can decide, what information is trusted, and how the next person knows that work is ready.
01 — OWNERSHIP
Name the decision.
A task can involve several people, but a decision still needs a clear owner. Distinguish the person doing the work from the person accepting the result.
Ask: who resolves an incomplete request?
02 — INFORMATION
Define the record.
A customer, item, or order can mean different things to different teams. Agree on the minimum information and the source that people should consult.
Ask: where is the current delivery date?
03 — EXCEPTIONS
Trace the detour.
The ordinary path is only part of the process. A late delivery, missing approval, or partial receipt reveals how work actually moves when a rule cannot be met.
Ask: what happens when the order changes?
02 / Make the handoff visible
Follow one request across the room.
A swimlane separates responsibility from sequence. Read left to right to follow the work; look up and down to see when ownership changes.
Start with an ordinary example. Then follow one exception through the same map. The gap between the two often gives the next conversation its focus.
Build a map with your team03 / Prepare for an ERP conversation
Bring evidence.
Leave assumptions open.
An ERP discussion becomes more concrete when the team can describe its current work. These artifacts help separate a process decision from a system requirement.
| Bring this | It helps answer | Watch for |
|---|---|---|
| One current-state map | Where does the work begin, and what makes it complete? | A map that quietly replaces today's work with an ideal future. |
| A sample record | Which fields, identifiers, and statuses carry the process? | Different teams using the same label for different meanings. |
| An exception log | Which detours need a decision, a rule, or better information? | Designing every step around one unusual case. |
| A question list | What must be learned before choosing the next step? | Treating an untested assumption as a fixed requirement. |
These are planning aids, not an implementation checklist. Scope, controls, and specialist review should reflect the actual organization and project.
04 / Better working conversations
Keep the map close to the work.
A diagram is useful when people can challenge it, explain it, and use it to locate the next problem.
Read our approachAsk for a recent example.
“How does approval work?” invites a general answer. “Show me the last request that needed approval” makes the conversation specific enough to inspect.
Keep current and future apart.
Record today's path first. Put proposed changes in a separate view so nobody mistakes an aspiration for an existing practice.
End with an owner and a question.
A useful workshop does not need to settle everything. Name the unresolved question, the person who will investigate it, and the evidence they will bring back.
A practical next step
Choose one process.
Draw what actually happens.
The guide takes you from a clear boundary to a reviewed map, using a small purchase-request example throughout.