Map the process before automating it

Before automating a workflow, watch it happen. The written procedure often describes the ordinary path, while the person doing the work spends much of the day handling incomplete requests, unclear ownership, and exceptions. Automating only the tidy version can move those problems into software without resolving them. A small process map gives you a way to see the work before deciding which part a tool should perform.

This guide is for an operator assessing a repeated business workflow, such as approving a supplier request, scheduling a service visit, or publishing an internal update. The aim is to identify one bounded change that can be tested and reversed. You do not need a complete model of the organization. You need a truthful account of a specific process, including what starts it, what finishes it, and what happens when the expected information is missing.

Choose a beginning and an end

A useful boundary names an observable trigger and a recognizable outcome. For a supplier request, the trigger could be a submitted request with the required attachments. The end could be a recorded approval or rejection communicated to the requester. If you start with the vague label supplier management, the map can expand indefinitely. Keep related work outside the boundary unless it directly changes the decision you are trying to automate.

Write down who receives the outcome and what they need from it. An approval may be insufficient if the purchasing team also needs a cost code and an agreed delivery date. That missing output often explains the follow-up messages that make a process feel slow. The ASQ SIPOC framework provides a way to identify suppliers, inputs, process, outputs, and customers before drawing the detailed flow.

Observe five real instances

Choose five recent cases and follow each from start to finish. Five is a practical starting sample for discovery, not a guarantee that you have found every pattern. Include an ordinary case and, where available, cases that were delayed, returned, or handled by someone else. Ask the person doing the work to show the records and messages they actually used. Memory tends to compress the awkward steps that are most useful to understand.

For each case, note when the request arrived, when someone began work, which information was missing, who made a decision, and when the outcome was communicated. Separate active work from waiting. A request that takes three days may involve only a few minutes of action and a long pause for an answer. That distinction matters because automating data entry will not necessarily remove the wait that dominates the experience.

Draw actions, decisions, and handoffs

Use simple shapes and familiar language. An action might be check attachment or assign reviewer. A decision might be is the request within the agreed budget? A handoff should name the receiving role, not merely point to a different box. The ASQ flowchart guide explains standard symbols and the use of flowcharts to understand a process. Keep the map readable enough for the people who perform the work to correct it.

Label the paths out of a decision. Yes and no can work for a clear question, but more specific labels may be better when a request can be incomplete, approved, rejected, or deferred. Show where a returned request re-enters the process. If the map has an arrow labeled ask someone, identify who that person is and what information they provide. Ambiguity in the diagram usually represents ambiguity that software will eventually have to confront.

Give exceptions a proper place

Ask what happens when the usual reviewer is unavailable, an attachment cannot be opened, a request arrives twice, or a decision needs to be withdrawn. These are ordinary operational conditions. They should have a visible route, even if the route is a manual review queue. A workflow that stops safely and explains what happened can be more useful than one that tries to improvise an answer outside its authority.

In an illustrative supplier approval process, a request may be returned for a missing insurance document. A second version then arrives through email while the original remains in a form system. If automation treats both as new requests, two reviewers could act on different versions. The map should reveal how identity and revision are handled before anyone writes the integration. Decide which record is authoritative and how a reviewer recognizes that it has been superseded.

Remove unnecessary steps before speeding them up

Review each action with its owner. Ask what purpose it serves and what would go wrong if it disappeared. Some steps provide a necessary control; others exist because information was once difficult to share. An approval copied to three people might be required for accountability, or it might be a habit from an earlier team structure. Do not remove controls casually, but do not assume that every repeated action deserves automation.

A simpler form, a clearer owner, or a shared definition can sometimes resolve the problem without a new system. If the requester already has the information, collecting it once may prevent several follow-up messages. If two reviewers repeatedly disagree, an automated reminder will not settle the policy question. Use the map to distinguish a tooling problem from an unresolved decision about how the organization wants to work.

Pick one safe automation boundary

Choose a step with clear inputs, a predictable action, and an observable result. For a first trial, that might be checking whether required fields are present and preparing a review packet. Keep the actual approval with the authorized person until the policy and exception handling are understood. The boundary should say what the automation may change and what it must leave for a human decision.

Define failure behavior before the happy path is considered complete. If a connected system is unavailable, where does the request remain? Can the operator retry without creating a duplicate? How is a partial update identified? Who receives an alert, and how can they inspect the underlying case? A process map will not answer every technical question, but it exposes the points where those answers are needed.

Test against the observed cases

Replay the five discovery cases through the proposed process using appropriate test data. Check the ordinary path, the returned request, the absent reviewer, and any duplicate or revised record you observed. Add cases for the specific failures the new automation introduces, such as a disconnected service. Compare the outcome with what the process owner intended, rather than merely checking whether the software executed its steps.

Choose a measurement connected to the original problem. If the concern was waiting for a reviewer, track that wait separately from total completion time. If the concern was missing information, examine how often a request must be returned and why. Also watch for new burdens, such as operators spending more time correcting automatic classifications. A shorter path on the diagram is not sufficient evidence that the working process improved.

Leave an owner and a way back

Assign someone to maintain the map and review exceptions after launch. Record the current version, the systems involved, and the circumstances that should trigger a review. A policy change, a new approval role, or a different source of requests can make yesterday's correct workflow incomplete. The map is useful when it remains close enough to reality to guide a conversation, not when it becomes a framed artifact nobody updates.

Finish the assessment with a concrete recommendation: the step to change, the expected benefit, the unresolved questions, the trial boundary, and the rollback method. Share it with the people who perform and receive the work. Their corrections are part of the design. Automating a process is easier to evaluate when everyone can point to the same map and explain what should happen, including the cases that do not follow the ordinary route.