Stop Automating Broken Processes: Map the Workflow First

Insights · 10 min read

A broken process does not become a good process when it moves faster.

If requests arrive without required information, automation can route incomplete requests more quickly. If three employees maintain separate spreadsheets, an integration can synchronise the disagreement. If nobody owns the approval, automated reminders can create more messages without creating accountability.

This is why process mapping should come before workflow automation. A map makes the real work visible: steps, decisions, handoffs, waiting, workarounds and exceptions. Once those elements are visible, the team can remove unnecessary activity and decide where technology will genuinely help.

Process mapping does not require a lengthy transformation programme. For many SME workflows, a focused session with the people who perform the work can reveal the majority of the problem. The key is to map what actually happens—not what the procedure says should happen.

What workflow mapping is—and is not

A workflow map is a visual description of how a piece of work moves from a trigger to an outcome. It shows actions, decisions, people or teams, systems, information and waiting points.

It is not merely a list of software screens. A process may move through email, conversation, paper, spreadsheets and business systems. The map follows the work across those boundaries.

It is also not a performance evaluation of individual employees. Workarounds often exist because people are compensating for missing information, unclear rules or unsuitable tools. The purpose is to improve the system of work, not blame the person holding it together.

Finally, the map is not the finished automation design. The current-state map helps the team understand the problem. A future-state map describes how the work should operate after simplification. Only then should technical design begin.

Why teams skip the mapping step

The current process may feel obvious. Everyone has seen the emails and spreadsheets, so a workshop appears unnecessary. A vendor demonstration may also create pressure to begin configuration immediately.

Yet employees often see only their portion of a workflow. The requester does not know how many times data is copied after submission. The approver does not see the follow-up messages sent before the request reaches them. Management sees the final report but not the manual reconciliation behind it.

Mapping brings these partial views together. It also separates process problems from tool problems. Sometimes the fastest improvement is a required field, one shared status or a clearer approval threshold—not a new platform.

Step 1: Define the outcome and boundaries

Start by naming the result in business language. Examples include:

• A new employee receives approved equipment and access by their start date.
• A purchase request is approved, rejected or returned for clarification with a complete record.
• A customer enquiry reaches the right person and receives an acknowledgement within one working day.
• A device handover produces an accurate, retrievable acceptance record.

Avoid vague outcomes such as “digitise procurement” or “use AI for enquiries.” Those are solution directions, not operational results.

Next, define the start and end. The start is a specific trigger: a submitted request, confirmed order or approved hire. The end is the observable result: recorded approval, issued document or completed handover.

Boundaries prevent the map from expanding into the whole business. Related processes can be noted without being solved in the same project.

Step 2: Bring in the people who do the work

Include representatives from each role involved, especially the people who handle exceptions. A manager alone may describe the intended procedure. Frontline employees can explain what happens when data is missing, the approver is unavailable or the system rejects an entry.

A useful group might include:

• The person who starts or receives the request.
• The employee who checks or processes it.
• The approver or decision-maker.
• The administrator who maintains the record.
• A technical or compliance representative where relevant.

Create a psychologically safe session. Ask participants to describe workarounds without fear that the workaround itself will be treated as misconduct. If the map is used to assign blame, the team will produce a neat fiction rather than a useful current state.

Step 3: Observe actual cases

Choose several recent cases: a normal case, an incomplete case, an urgent case and a case that went wrong. Follow each from start to finish.

For every step, capture:

• What triggers the step?
• Who performs it?
• What information is required?
• Which system, document or communication channel is used?
• How long does active work take?
• How long does the item wait?
• What decision is made?
• What record is created?
• What can go wrong?

Evidence is more reliable than recollection. Review timestamps, forms, emails and system histories where appropriate and authorised. Do not collect unnecessary personal or confidential content for the workshop; the sequence and data fields are usually enough.

Step 4: Draw lanes, steps, decisions and handoffs

A simple swimlane map is often sufficient. Each horizontal lane represents a role or team. Place actions in sequence within the relevant lane. Use diamonds for decisions and arrows for movement.

The map should include waiting and rework, not only productive actions. Mark when an item sits in an inbox, returns for missing information or is copied into another tracker. These moments frequently contain more improvement potential than the formal processing steps.

Use plain language. “Check required fields” is more useful to business participants than a technical system label. Add the system or file underneath the action when needed.

Do not spend the session perfecting diagram notation. Accuracy and shared understanding matter more than professional-looking symbols.

Step 5: Find the friction

Review the current state using several categories.

Duplicate entry

Where is the same information typed more than once? Duplication creates effort and disagreement when one copy changes and another does not.

Waiting

Where does work sit without an owner or deadline? Compare active handling time with total cycle time. A process may require 20 minutes of work but take five days to finish.

Rework

Which steps are repeated because information is missing, unclear or incorrect? Identify why the defect was not prevented earlier.

Unclear decisions

Where do employees ask a manager what to do each time? A missing threshold or policy may be the real cause.

Invisible status

Where do people send “Any update?” messages because they cannot see progress? Status visibility can remove work for both requester and processor.

Unnecessary approvals

Does every case require approval even when it falls within an agreed limit? Controls should match risk rather than add identical delay to every request.

Single-person dependency

Which step relies on one employee’s memory, personal files or account? This creates continuity risk even when the person performs well.

Unmanaged exceptions

What happens when the normal path does not apply? An automation-ready process needs an exception route, not an assumption that exceptions will disappear.

Step 6: Ask whether each step should exist

Before automating a step, challenge it. Use five possible actions:

1. Eliminate: remove work that no longer serves a purpose.
2. Prevent: improve the input so rework does not occur.
3. Combine: merge duplicated checks or records.
4. Clarify: define ownership, rules or service levels.
5. Automate: use technology for stable, repetitive movement or transformation.

This sequence matters. Eliminating a step provides a 100% reduction without licences or maintenance. Preventing missing information may be better than using AI to interpret incomplete emails. Clarifying an approval threshold may remove most escalations.

Automation should be applied to the useful work that remains.

Step 7: Design the future state

The future-state map should describe a realistic operating process, not a product demonstration. Show:

• The structured trigger.
• Required information and validation.
• Automated steps.
• Human decisions and approval points.
• Exception handling.
• System of record.
• Notifications and status visibility.
• Failure and fallback path.

For example, a purchase request may move from email to a structured form. Required fields are validated immediately. Low-risk requests within policy route to the appropriate approver; unusual requests go to a procurement or management queue. The requester can see status. The final decision and supporting record are stored together.

This future state removes duplicate entry and chasing before any integration is configured.

A worked example: digital equipment handover

Imagine an organisation handing laptops from one employee to another. The original process uses a paper declaration and a photograph. An administrator later types details into a spreadsheet and manually assembles evidence when a dispute occurs.

The current-state map may reveal:

• Serial numbers are typed multiple times.
• The declaration is occasionally incomplete.
• Images and records are stored in different folders.
• The receiving employee cannot easily receive a copy.
• Retrieval depends on knowing the naming convention.

The future state might use a structured form with required equipment details and declarations. Submitted information generates a consistent PDF record with a timestamp and references to approved evidence. The record is stored in an agreed location and shared with the relevant parties.

Technology produces the document, but the mapping work defines the important controls: which declarations are required, who confirms the handover, where the official record lives and how an error is corrected.

That distinction prevents a technically successful document generator from becoming an operationally unreliable record.

A 90-minute SME workflow-mapping workshop

For a bounded process, use this agenda:

0–10 minutes: Outcome and scope Agree on the trigger, end result and reason for improvement.

10–35 minutes: Current-state steps Follow one normal case through every role and system.

35–50 minutes: Exceptions and evidence Add incomplete, urgent and failed cases. Mark active and waiting time.

50–65 minutes: Friction review Identify duplication, delay, rework, unclear ownership and single-person dependency.

65–80 minutes: Future-state design Eliminate, prevent, combine and clarify before selecting automation candidates.

80–90 minutes: Actions and owners Assign the next evidence-gathering, policy and technical tasks.

The session should end with open questions, not hide them. Unknowns are useful outputs when someone is assigned to resolve them.

Information to capture beside the map

The diagram alone is not sufficient. Maintain a small process definition containing:

• Process name, owner and purpose.
• Trigger and completion criteria.
• Expected volume and peak periods.
• Required data and source systems.
• Decision rules and approval authority.
• Common exceptions.
• Service-level expectation.
• Records and retention needs.
• Access and confidentiality requirements.
• Baseline performance measures.
• Manual fallback.

This becomes the foundation for vendor discussions, configuration, testing and handover. It helps the organisation evaluate whether a proposal solves the real problem rather than merely demonstrating attractive features.

Common mapping mistakes

Mapping only the happy path

The normal path may be easy. Exceptions consume the time. Include missing information, unusual amounts, unavailable approvers and system failures.

Starting with the desired tool

If every map ends inside the product already selected, alternatives may be ignored. Describe the operational need before deciding the technical mechanism.

Treating every complaint as a requirement

One frustrating incident does not always justify a permanent step. Look for frequency, consequence and root cause.

Automating informal approval

Technology can expose a governance gap but cannot decide who should have authority. Agree on the policy first.

Ignoring maintenance

The future state should show who updates rules, templates, access and integrations. A workflow changes when the business changes.

How to know the map is ready for technical design

The team should be able to answer the following consistently:

• What outcome does the process produce?
• What information starts it?
• What is the normal path?
• Which decisions are rule-based?
• Which decisions remain human?
• What are the main exceptions?
• Where is the official record?
• Who owns performance and change?
• How will improvement be measured?
• What happens when automation is unavailable?

If important answers remain unknown, resolve them or limit the pilot accordingly.

Make work visible before making it faster

Workflow mapping is not bureaucracy. It is a practical way to prevent technology from hardening a poor process.

The map helps employees see the whole flow, not only their task. It gives management evidence about delay and rework. It gives a vendor clearer requirements. It gives the eventual automation an owner, boundaries and exception path.

Most importantly, it creates the opportunity to remove work before paying to automate it.

Start with one real case. Follow the work across people and systems. Mark what waits, repeats and depends on memory. Design a future state that is simpler and more accountable. Then automate the stable parts.

That order may feel slower during the first meeting. It is usually much faster over the life of the solution.

Sources and further reading

• Enterprise Singapore: Productivity and digitalisation
• IMDA: SMEs Go Digital and CTO-as-a-Service