Practical guide
AI fluency for process improvement: test a bottleneck
Separate working time from waiting time in a fictional approval process and design a small test without inventing a cause.
Process improvement managers can use AI to organize process evidence while checking what a proposed change would actually affect. This fictional approval exercise separates elapsed time, active work and waiting. It produces a testable improvement hypothesis, not a claim that a particular delay has a proven cause or an established remedy.
Describe the process from observable events
A process map should distinguish recorded transitions from explanations of why they happened.
A fictional request is submitted Monday at 09:00, reaches an approver Tuesday at 09:00 and is approved Tuesday at 10:00. The preparation log records thirty minutes of active work. The approval log records fifteen minutes of active review. The packet does not explain the rest of the elapsed time.
Ask AI to build a timeline with a source for each event. Do not label the whole first day as inefficient preparation or the final hour as continuous review. The timestamps show boundaries; the activity records describe only the work they actually captured. Keep unobserved intervals explicitly unresolved.
Calculate the quantities without mixing them
Elapsed time and recorded work time answer different questions.
From Monday 09:00 to Tuesday 10:00, twenty-five clock hours pass. Recorded active work totals forty-five minutes. This is not a business-hours calculation: the case supplies no working calendar. State that distinction before comparing the numbers. Do not silently subtract overnight hours or assume people were available throughout.
The difference does not prove that all remaining time was avoidable waste. It may include working-calendar effects, batching or unrecorded activity. List those as possible explanations, not findings. Ask the owner which missing events would distinguish them before choosing a process change.
Choose a hypothesis with an observable mechanism
A useful experiment states what changes and what should be observed if the explanation is right.
Suppose a fictional note says requests are forwarded once each morning. That supports investigating a batching delay, but one case does not establish its typical size. Propose comparing immediate forwarding with the existing daily forwarding schedule under approved, bounded conditions. Leave approval authority unchanged.
Record submission time, forwarding time, first review time and completion time for both conditions. Also record incomplete requests, because a faster handoff that increases rework may not improve the overall process. AI can draft the observation sheet, but the test owner must approve the actual change.
Keep a local improvement from becoming a system claim
Speeding one step may leave the end-to-end constraint unchanged.
Introduce a new fact: the approver reviews only at 09:00. Immediate forwarding after that time may still wait until the next review window. The proposed forwarding change therefore does not automatically shorten every request. Revise the hypothesis to show when it could matter and when it would not.
Avoid moving the bottleneck by requiring someone else to monitor requests continuously without agreed capacity. Describe the operational cost of the trial and a stop condition for missed or duplicated requests. No time saving should be reported until the corresponding observations actually exist.
Write a decision note that can reject the original idea
The final output should make an inconclusive or negative result useful.
Deliver the timeline, clock-hour calculation, known active work, unresolved intervals and proposed test. State the evidence that would support changing the forwarding rule and what would indicate a different constraint. Preserve the original hypothesis so later interpretation cannot quietly rewrite the reason for the experiment.
Review whether the worker distinguishes a measured timestamp from an inferred cause and notices the approver-window counterexample. This task differs from shift planning: it investigates the mechanism of a delay rather than assigning a fixed amount of work to a fixed capacity.
Sources and scope
NIST: AI risk management. Skills England: workplace AI foundations.
These references provide background, not validation or endorsement of this exercise. The case details, calculations and suggested review questions are original instructional material. Use them to discuss observable work, not to infer customer outcomes, professional credentials or performance in every setting. Before adapting the exercise, confirm the relevant facts, approved tools, data permissions and decision owners. If you change the case, revisit the expected answers and checks as well. These examples describe practice tasks, not a promise that a particular product includes the fictional features.
Sources: [1] [2]
Sources
- 1.AI RMF Core · NIST
- 2.AI foundation skills for work benchmark · Skills England