How to Map Existing Workflows Before Introducing Automation

01Choose a transaction and define its boundaries

Define the event that starts the process and the output that ends it. For supplier approval the trigger might be a request to use an external provider, while closure may require an authorized supplier status and communicated restrictions. If scope stops when procurement sends an email, the map cannot explain whether operational users received the correct decision.

Use a small sample of real cases covering routine, urgent, rejected and reopened transactions. Note the site, systems involved, actors, elapsed steps, approvals and relevant documents. Avoid relying solely on workshops with managers who rarely perform the process.

A concise SIPOC or swimlane diagram can be useful, but labels are not the evidence. Record where a source value originates, where it is copied, and what condition determines whether work may continue. The boundary should include external-party handoffs when they materially affect the outcome.

Technical context: ISO 9001:2026 — Quality management systems — Requirements is one verified source for the concepts discussed here.

02Observe work and reconcile conflicting descriptions

Shadow the person who performs each step. Ask them to show a recent case without rehearsing it, including where they looked for current instructions and how they handled missing information. Compare this with the documented procedure and the account given by another shift or location.

Unwritten rules often exist for sensible reasons. A production supervisor may use a temporary paper receipt during network loss, or a compliance officer may require an additional regulatory check for particular materials. The redesign should preserve valid safeguards rather than automatically classifying every manual step as waste.

Document divergences as design questions: Is the official path obsolete, is the exception unauthorized, or is the policy missing a legitimate branch? Decide with the process owner before translating the process into conditional software rules.

To expose delays, annotate actual waiting time separately from working time. A corrective action may need only thirty minutes of specialist review yet remain open for weeks because its evidence sits in an unattended mailbox. Software that simply transfers the case between inboxes can preserve the delay. The map should therefore show the queue owner, entry criterion, escalation rule and allowed next action. That detail gives designers a basis for notifications that trigger a legitimate decision rather than creating another stream of reminders.

Use a specific nomenclature ledger when departments use different words for the same activity. For example, an operations team may call a supplier “active” after a purchase order, procurement may mean financially onboarded, and quality may reserve “approved” for technical qualification. The workflow map needs to represent these as different states or decisions. If the future system collapses them into one convenient status, it can unintentionally authorize buying from a provider that has not met essential acceptance criteria.

03Map decisions and accountability separately from tasks

A task map describes activities; a decision map identifies who has authority to approve, reject, override or release. Systems are particularly vulnerable when every actor can move a ticket forward but no one is accountable for the final outcome.

For each decision capture inputs, required competence, segregation conditions and evidence. A person may recommend closure of a corrective action while another verifies its effectiveness. A digital workflow should preserve those distinct actions instead of introducing one generic Complete button.

Use a responsibility matrix only to clarify actual decision rights. A RACI chart cannot compensate for contradictory approval rules. Compare the chart with approved delegation records and recent transactions before using it to configure access.

A process map is incomplete if it shows only formal departments. Consider temporary workers, external laboratories, contracted service desks and customer representatives whose actions can determine whether a requirement is met. Show what they receive, when a response becomes binding, and which internal role owns a missing response. Include the non-digital evidence used during a service outage. This detail prevents automation designers from assuming that every important handoff occurs through a corporate login.

04Expose queues, loops and failure branches

Most delays occur outside the neat main path: missing specification, returned approval, late supporting evidence, unrecognized supplier ID or disputed corrective action. Map how a case waits, who is alerted and how it returns to the normal path. An automation that ignores these branches may strand work indefinitely.

Count how often a case changes hands and why it is sent back. Distinguish value-adding verification from avoidable re-entry. A second independent check can be essential in a high-risk process, even if a simplistic efficiency metric marks it as duplication.

For each exception define what staff can do, what must be escalated and how the case is closed. If no valid decision rule exists, identify the policy change required before designing software.

05Capture systems, data lineage and record meanings

Create a data-flow view beside the activity map. Identify the authoritative source for document version, customer number, supplier status, employee competence and due date. Record where fields are transformed or retyped. A workflow may run smoothly on screen while silently linking the wrong versions of records.

Define business terms and their allowed values. Approved may mean commercially approved in one system and technically qualified in another. If those meanings collapse into a single status, the software can permit use before a critical review is complete.

Record provenance, retention and evidence requirements. ISO 15489-1 provides useful principles for records and metadata, while ISO/IEC 25012 offers a framework for considering structured-data quality. Neither removes the need to map the organization’s actual fields and obligations.

06Design the future state with front-line participation

Build a future-state map only after the current-state issues have been classified. Remove redundant copying, clarify approvals and standardize ordinary terminology. Preserve the control evidence necessary for customer, regulatory and management-system obligations.

Involve operators from at least two conditions that differ materially, such as day and night shifts or central and remote sites. Check whether proposed required fields can be completed at the actual point of work. A field that can only be populated later will create guessed entries or a shadow register.

Demonstrate the future path using realistic transactions and exceptions, not only an abstract diagram. Mark where automation ends and human professional judgment remains necessary. The resulting specification should be intelligible to both process owners and developers.

When validating the future state, walk through a case using the actual forms, devices and reference data available on a busy shift. A field that seems obvious at headquarters may require the operator to stop work and telephone a remote manager. Identify an approved way to proceed or route the case for review; do not normalize invented values. A working map needs to show both how compliant work continues and how incomplete work is prevented from being wrongly released.

07Approve the map as a controlled baseline

Agree the version, process boundaries, ownership, exception paths, interfaces and acceptance checks before configuration. A draft map used informally by a vendor can become an undocumented requirement and cause later disputes about whether the delivered system is correct.

Preserve a trace from each key requirement to the mapped step and expected evidence. Change the design when a pilot reveals new facts, but record the reason and assess the impact on related workflows. An evolving baseline can still be controlled.

Use completed test cases to verify the map rather than celebrating the diagram’s appearance. The map succeeds when it enables reliable work, identifies unresolved decisions and prevents important controls from disappearing in the software translation.

Validate each handoff by asking the receiving person what information they must trust before continuing. A map often records that Quality sends an approved instruction to Production; the critical requirement may be that Production receives the correct revision, knows when it takes effect and can withdraw older copies. The receiving person should identify the missing information, supporting proof and circumstances that prevent use. A reliable map links the sending action to the receiving control, not merely to a message arrow.

At the final walkthrough, challenge the process with an ordinary transaction, an urgent case, rejected evidence and a temporary system outage. The purpose is not to design every rare event in excessive detail but to establish safe routes for the classes of exceptions that matter. Record which questions remain open, the authorized person to resolve each one and the impact on configuration. A map with documented uncertainties is more useful than a visually perfect diagram whose critical decisions were assumed.

The approved process map should be maintained as a living control reference. When staff invent a new workaround or a supplier changes its handoff requirements, record the observed path and decide whether the mapped process remains suitable. Reviewers should be able to connect a workflow configuration change with the process decision it implements. The resulting record can support both training and internal audit without becoming a duplicate procedure manual; its strength is in showing boundaries, accountability and exceptions clearly enough to guide action.

Closing Perspective

Map decisions, exceptions and record lineage before mapping screens. A faithful current-state view is the foundation for a safer future process.