Mapping AI Opportunities on a Process Map

The most common mapping mistake is documenting the official version. The map you want is the observed version: who really does what, in what order, with which workaround. Capture it in five to nine steps. Fewer and you have hidden the friction; more and nobody reads it.

Run the session with the people who touch the work, not just the process owner. Gather the manager, the analyst and, where relevant, the customer's point of view before drawing anything, because projects go sideways when an important participant is left out of the room early (ClickUp's process mapping walkthrough). A whiteboard or a shared doc is enough. Fancy tooling can come later.

Lay the map out as swimlanes, one horizontal band per role or system. Each step sits in the lane of whoever performs it, and every time the work crosses a lane boundary, you have drawn a handoff. This structure is what makes friction visible: a step that bounces between four lanes costs coordination even when each individual task is quick.

A minimal map template in text form looks like this. Sketch the same structure on a whiteboard, one column per swimlane.

Lane: Sales          | Lane: Finance        | Lane: Legal
---------------------|----------------------|---------------------
1 Receive request    |                      |
2 Enter deal in CRM  |                      |
   -- handoff -->    | 3 Check pricing      |
                     | 4 Wait for approval  |
                     |    -- handoff -->    | 5 Review contract
                     | 6 Issue invoice      |

Keep three rules while drawing. First, record the real sequence, including the email that bypasses the system. Second, note the volume and cycle time of each step from a system report or a rough count, because estimated numbers that are never checked become the basis for a business case later. Third, mark every place the work waits: for an approval, for a person to return from a shift, for a batch job to run overnight. Waiting is where maps usually reveal the biggest surprise, and it is invisible on most org charts.

If the process is long, split the map rather than compressing it. A map of a 30 step process drawn in nine boxes hides the very steps you are hunting for.

Labels do the analytical work. Once every step carries a type, patterns jump out: clusters of data entry, chains of reviews, handoffs that add days without adding value. Use exactly five labels.

The labels map onto the two broad categories of AI value that show up repeatedly in practice: automation and optimization on one side (high volume repetitive data tasks, real time decisions) and insights and predictions on the other (forecasting operations needs, flagging risk) (Savvi). Data entry and review steps lean toward the first category. Waiting and decision steps often lean toward the second.

Two warnings about labeling. A step that contains both judgment and typing gets two labels only if you split it into two steps; otherwise pick the dominant type and note the other in a comment. And a handoff that exists for compliance reasons, such as a mandatory sign-off, should be marked as such. You are not going to remove it, so the AI opportunity there is faster evidence gathering, not elimination.

Label honestly and the map starts to argue with you. A process with nine labels and six of them reviews is telling you something about culture as much as workflow. That is useful. Reviews that add no decision value are exactly the kind of friction a first AI pilot can remove without touching anything risky.

Now turn the labeled map into a ranked list. Keep the scoring deliberately small: three questions per step, each answered on a 1 to 5 scale by the people who do the work. More criteria produce more debate and less action.

1. Failure frequency. How often does this step go wrong or need rework? A step that fails weekly scores high; one that fails once a quarter scores low.
2. Time weight. How much total human time does this step consume per cycle, including the waiting it causes downstream?
3. Judgment requirement. How much of this step genuinely needs human experience, context or accountability? Score high when judgment is heavy, low when a careful rule could cover it.

The decision rule is simple: high failure frequency, high time weight and low judgment requirement is the first AI candidate. High judgment flips the treatment: keep the human in the loop and use AI to prepare the inputs, summarize evidence or draft a recommendation for approval.

A worked example makes the arithmetic concrete. Suppose a credit team processes 600 applications a month and maps five steps. Scores are out of 5, and the priority score is frequency plus time weight plus (6 minus judgment), giving a maximum of 15.

Data entry scores 14 and becomes the pilot. The credit decision scores 9 not because it is unimportant but because judgment is high; the right intervention there is AI that assembles the file and drafts a rationale, with a human deciding. Notice that the waiting step scores 11, higher than the handoff, which is the sort of result a gut-feel list usually misses.

Translate the top two or three steps into measurable task statements before writing any code. "Extract 12 fields from supplier invoices into the ERP" is a task. "Automate finance" is not. Ng's point that AI is good at automating tasks rather than whole jobs is the discipline that keeps this step honest (HBR). Attach a number to each task: minutes saved per cycle, error rate today, cycle time today. A framework without a metric invites the shrug that kills programs, which is why prioritization frameworks insist on measurable KPIs rather than vague terms like productivity (Savvi).

The map gives you candidates. It does not, by itself, tell you what to fund. Prioritization is a separate discipline from discovery, and it rewards ruthlessness: the point is to say no to most of what the map surfaced (Agility at Scale's use case prioritization framework). Keep that distinction explicit in your document so nobody mistakes a long list for a plan.

Apply three gates before anything reaches a steering meeting. First, the value gate: does the step move a business metric such as cost per transaction, cycle time, or error rate? Second, the data gate: can the required data be accessed at the needed cadence and quality, or can the gap close quickly? Third, the ownership gate: is there a named person who will act on the AI output, and a system into which it will connect? No owner, no go (Umbrex's AI use-case prioritization framework). These gates prevent the classic failure where a pilot succeeds in a demo and dies in production because no one owned the decision it was supposed to inform.

Layer a small weighted score on what survives. A common weighting splits value at roughly 35 to 45 percent, feasibility at 25 to 35 percent, time to value at 10 to 15 percent, reusability at 10 to 15 percent and risk at 5 to 10 percent, using clear descriptors for each point on the scale to reduce bias (Umbrex). You do not need the full apparatus for a first map. You do need to show that the shortlist was chosen against shared criteria rather than by whoever spoke loudest.

One pattern worth checking before you commit: the same AI capability often serves several steps. An extraction model that reads invoices may also read purchase orders and contracts. Score reusability accordingly, because a pilot that leaves behind a reusable component is worth more than one that solves a single step perfectly and nothing else (Umbrex).

Finally, hold the map's scope to something reviewable. A first pilot should be meaningful enough that success convinces other leaders to invest, and small enough to finish quickly (HBR). A map that produces a 40 item task list has failed the exercise. A map that produces five tasks, one of which you can start next month, has succeeded.

A process map is not a one-time deliverable. Processes drift: a new approval gets added, a system changes, a team reorganizes. When the map is stale, the AI opportunity list built on it is stale too. Set a review cadence and treat the map as a living document that the process owner maintains, not a consulting artifact that gets filed.

There is a second reason to keep it current. The map is the evidence base for your next pilot. When the first one lands, you go back to the scored table, remove the step you fixed, rescore the rest and pick the next candidate. Teams that run this loop two or three times stop asking "where do we start with AI" and start asking "which three steps are next." That shift is the real return on the mapping exercise.

Two practical habits make the loop work. Keep the raw scores and the metric for every step, so improvements are measured against the baseline you recorded rather than against memory. And keep the human judgment score visible, because the tempting failure mode after a successful automation pilot is to point AI at a high judgment step next and quietly remove accountability. The score column is your guardrail.

If your team lacks the specialist skills to take a mapped step into production, that is a resourcing problem, not a reason to widen scope. You can narrow to one step and bring in help or use a partner, rather than waiting until an internal AI team is complete before executing, which is usually too slow relative to the pace of change (HBR). For teams that want senior operators to take a mapped workflow and return finished work, Quanta Experts is built around that model: each expert reads your context, does the work and hands back deliverables.