Lock the process and what it costs before you look for AI

Many AI ideas arrive as a tool looking for a problem. Someone has seen a demo, and the question in the room is where to put it.

I start the other way around. First I lock how the work runs today and what that costs. Only then do I look for places worth improving, and AI is one possible answer among several. This is Discovery, stage 1 of 4 in the order I use: Discovery, Assessment, Solutioning, then Adoption and Improvement. The method is written up in the AI Project Discovery Framework. Here it is on one small example.

The example is entirely made up for illustration. To keep the story readable, I tell it in the first person, but every company, person, event, workflow detail and number below is invented. People appear by role only: the lab coordinator, the process owner and a quality assurance (QA) reader.

What this covers

• Value first. Lock the as-is process and its baseline before anyone names a tool.
• Map what people actually do. The standard operating procedure (SOP) is the starting point, not the map.
• Put numbers on it. No baseline yet? Measure one, even from a short sample.
• Ask where the data lives. For every step.
• Flag, record, do not judge. The decision waits for Assessment.
• Lock it, then find candidates. A light screen, a sort by baseline, a short list.

Value first, then the tool

The idea in my example arrived the usual way. A lab-supply team wanted “an AI tool that reads the supplier emails and fills in our tracking sheet.” Nobody had written down what the current way of working costs.

My recommendation: when the idea comes first, do not assess the idea yet. Map the process it touches, then see whether the idea still looks like the answer.

Two terms matter here. The baseline is today’s measured numbers for a step, taken before anything changes. The value at stake is what the pain costs today, taken from the baseline. It is not a promise of savings. Discovery supplies both. It does not declare the value case. That happens in Assessment, where each metric gets a target, an owner and a check date, and the value is netted against the full cost.

Here, full cost means the lifetime cost of building, integrating, validating, running and retiring the change.

Map what people actually do

I asked for a walk-through, not a desk exercise. The lab coordinator, the process owner and one lab technician sat down with the SOP on one screen and the real inbox on the other.

The SOP described a tidy flow. The supplier sends a test result for a lot of material. The result is filed in the document system, the coordinator transcribes the values into the tracking sheet, and the lab checks the sheet before using the lot.

The walk-through showed something different. Results arrived as spreadsheets attached to emails, sometimes to the coordinator’s own inbox and sometimes to a shared one. Filing in the document system happened later, if at all, and attachments often ended up in a personal folder. When the coordinator was away, a colleague did the step from memory.

Made-up example: the flow the SOP described next to what the walk-through showed. The gap between them goes on the as-is map.

The gap between the SOP and the real flow is where the pain and the risk tend to sit, so I wrote it down as part of the as-is process. The flow we agreed on had five steps:

1. A supplier emails a test result for a lot.
2. The coordinator checks the result against the specification and decides whether the lot is released for use or held while the supplier is asked a question.
3. The coordinator copies the result into the tracking sheet.
4. A QA reader checks the sheet against the emails from time to time.
5. Lab staff look up the sheet, or ask the coordinator, before using a lot.

Put numbers on it

Step 3 had no number, so we measured one. The coordinator kept a tally for a two-week sample. It showed about 2 hours a week of re-keying supplier results, and the QA reader found 3 typos in the sheet over the same period. The frequency is weekly. That is the baseline for step 3.

Everything else stayed unknown, on purpose. How often a lot is held at step 2: we have no number yet, so it stays on the list as unknown. How long the QA check takes, and how often someone walks over to ask: unknown. I would rather hand over “unknown, to be measured” than a guess.

A recurring problem is weak business-side commitment to establishing the baseline. The people doing the work are the ones who can estimate its real duration, and even a short sample can start the measurement.

Ask where the data lives

For each step I asked where the data lives, who owns it, whether it is correct and complete, whether it is clearly defined and structured, and whether people can find it without asking.

• Step 1, the emails. Several inboxes and personal folders. No single location, no named owner.
• Step 2, the specification. A controlled document owned by QA. Defined and easy to find.
• Steps 3 and 5, the tracking sheet. A shared drive. The coordinator owns it in practice, though that is written nowhere. The column meanings are not documented, and one column is used two different ways.
• Step 4, the QA check. Where the result of the check is recorded, nobody could say. Unknown.

My assessment: the data foundation is the quiet half of the problem. When information is hard to locate or interpret, the process already loses time, and any later improvement starts with a constraint.

One rule while mapping: do not paste supplier results, or any regulated or confidential data, into external AI tools.

Flag it, record it, do not judge it

Two things came up that I was tempted to decide on the spot.

The first was the filing problem at step 1. It looked like a broken process, and a shared location for the emailed files looked like the obvious fix. I wrote it down as a flag. The decision belongs to Assessment.

The second was the GxP (good practice rules for regulated pharma) question. Does step 3 create or change a GxP record? Does step 2 affect a product-quality decision? The honest answer in the room was “unsure,” so that is what I recorded. Capture the fact, judge it later. I noted the ALCOA+ expectations that would apply if the answer is yes (attributable, legible, contemporaneous, original, accurate, and also complete, consistent, enduring and available). Validation effort is unknown at this stage, so I did not estimate it. How much validation a candidate needs depends on its context of use, which I cover in How much validation does your AI actually need?. I did ask a QA reader to look at the candidate list early, as an informed reader, not an approver.

Lock it

The process owner, the lab coordinator and the lab technician agreed the flow, the SOP gap, the baseline and the unknowns. We wrote the version and the date on it and set a time limit for the mapping. If the process changes, the map is re-opened and the baseline is taken again.

Made-up example: the locked as-is flow. Only step 3 has a measured baseline; every other number is an honest unknown, and each step shows where its data lives.

My recommendation: do not skip the lock, and do not let the map drift. Re-open it and take the baseline again whenever the process changes.

Find candidates on the flow

With the flow locked, the invented team walked it again. They marked repetitive, slow, error-prone or text-heavy work; rework and handoffs; single-person knowledge; costly failures; key decisions; and the data behind each step. A keyword match alone was not enough: each candidate needed a measured number or an explicit “unknown.”

The release-or-hold decision at step 2 is neither slow nor repetitive. But a mistake in it is costly, and it rests on one person’s knowledge of the specifications and the suppliers. That makes it a key decision, and it stays on the list for that reason.

Light screen

Every candidate faced three yes/no/unknown checks: Is the pain frequent or costly? Is there an owner who can answer questions? Is usable data available, or is there a credible path to access it?

A candidate is dropped only on a clear “no,” with the reason written next to it. An “unknown” stays in, with the open question beside it. Dropped rows are kept for when the data, process or rules change.

One candidate was dropped. A technician had asked whether AI could check the supplier’s own testing before the result was sent. That step runs inside another organization, and nobody in the team will answer questions about it. A clear “no” on the owner question, so the row was dropped with its reason and kept at the bottom of the list.

The only measured baseline came first; the remaining rows stayed explicitly unordered until their baselines could be measured. This is sequencing, not a merit score. Discovery does not choose a technology, net full cost or design anything.

The list handed to Assessment

1. Re-keying supplier results (step 3). Pain: about 2 hours a week and 3 typos found in review, from a two-week sample; weekly. Felt by the lab coordinator and the QA reader. Data: emailed spreadsheets, no single location, owner not named. GxP: unsure. Keep (frequent; owner to be confirmed).
2. Release-or-hold decision (step 2). Pain: not measured; a wrong call is costly and depends on one person. Felt by the coordinator and the lab. Data: the controlled specification (QA) and the emailed result. GxP: unsure. Keep (key decision; baseline to be measured).
3. Finding a lot’s result before use (step 5). Pain: staff cannot find the entry and ask in person; frequency unknown. Felt by lab staff and the coordinator. Data: the tracking sheet, columns undefined. GxP: unsure. Keep (unknown; count the asks over a short sample).
4. QA cross-check of the sheet (step 4). Pain: rework; time unknown. Felt by the QA reader. Data: the sheet and the inboxes; check record location unknown. GxP: unsure. Keep (unknown; owner to confirm time spent).
5. Checking the supplier’s own testing (outside the flow). Dropped: no owner in the team, no path to the data. Kept for revisiting.

Made-up example: three light-screen checks, then the short list. The measured row comes first, the rest stay unordered, and the dropped row is kept with its reason.

Each row goes to Assessment with the locked as-is flow and the baseline behind it. Assessment takes one candidate at a time. For each, it confirms the target, owner and check date, sorts the candidate into one of four buckets, and nets value against full cost. It may well decide the first row is a process fix, a shared location for the files, and not AI at all. That is a valid result. I describe that stage in The most valuable AI call you’ll make is often “not this one”.

Good questions for your next process walk-through

• Where does this process differ from its SOP, and why?
• Does every step have a number next to it, or an honest “unknown”?
• For each step, where does the data live, who owns it, and can anyone find it?
• Are you sorting by baseline, or have you started scoring?

The full method, including the candidate-list template, is in the AI Project Discovery Framework.

A locked flow for the facts, a baseline for the value, and the tool decided last.

---

Want to map your process and its value with me? That is the work I do.