A request for AI is sometimes a request to repair work that should never have become so complicated. A team wants an assistant to chase approvals, reconcile conflicting records or explain why a case is still waiting. Before choosing a model, I would ask a more basic question: what is preventing the work from moving?
If the obstacle is an unnecessary handoff, an unclear rule or missing information at the start, adding intelligence may make the workaround more sophisticated without removing the cause. The useful leadership decision is whether the process needs AI, simpler automation or redesign first.
This is a practical extension of the process inventory and workflow-mapping approach in my VORTA material. Operational readiness means understanding how work actually happens, including the points where it stops. It does not mean making every process perfect before experimenting with AI.
Distinguish work time from waiting time
Consider an illustrative supplier-onboarding process, not a client case. An employee checks a submission, asks for a missing document, waits for a manager, then copies the same information into another system. A proposed AI assistant would summarize the documents faster.
That may be useful. But if the case spends most of its elapsed time waiting for missing information and approval, a faster summary addresses only part of the problem. Measure the stages separately before presenting the assistant as the solution to slow onboarding.
- Active work: time spent reading, checking, entering information or making a decision.
- Waiting: time between a request and the next authorized action.
- Rework: repeated effort caused by incomplete, conflicting or incorrectly handled information.
- Handoffs: transfers between people or systems, including transfers that add no new decision or information.
Do not assume every wait is waste. A required verification or separation of duties may protect the organization. The question is whether the delay serves a clear purpose and whether the same protection could be delivered with less friction.
Follow one case from request to completion
Start with a small set of recent cases that includes ordinary work and exceptions. Follow the records and speak to the people doing the work. A procedure describes the intended process; the case history reveals what happened.
For each stage, record the input, action, decision, responsible role and output. Note where information was requested again, where a person had to guess which rule applied and where a case waited without a visible owner. Record what is observed separately from what a participant estimates.
This is a diagnostic exercise, not a statistically representative performance study. A few cases can reveal a credible failure mechanism, but they cannot establish how frequently it occurs across the business. Validate recurring patterns with broader records before estimating savings.
Ask the person receiving each handoff: “What must be true for you to act on this?” Their answer often exposes a missing field, an ambiguous approval condition or a dependency that the upstream team did not know about.
Choose the smallest change that addresses the cause
For each source of delay or rework, consider the following options before committing to AI.
Remove work that has no necessary purpose
If two teams collect the same information for the same purpose, investigate whether one collection can serve both. If a report is produced but nobody uses it to decide or act, confirm its obligations and purpose before automating its production.
Removal needs an accountable decision. A step that looks redundant may support a contractual obligation, an audit requirement or an important control. Consult the relevant owner rather than deleting it because it is inconvenient.
Clarify the rule or the handoff
If employees receive different answers to the same policy question, the first task is to establish an authoritative rule and an exception route. A model should not become the informal author of a policy that management has not settled.
In the onboarding example, the improvement might be a clear list of required documents, a named approval role and a visible reason when a case is returned. That is process design even if it is delivered through a digital form.
Automate a stable, repeatable step
When the rule is explicit and the inputs are reliable, ordinary automation may be sufficient. A complete submission can create a task for the correct owner. An overdue task can trigger a reminder. A validated field can populate another system without being retyped.
The automation still needs testing, permissions and exception handling. “Not AI” does not mean “no risk.” It means the solution can follow a defined rule without asking a model to interpret it.
Add AI where interpretation creates useful value
AI becomes a stronger candidate when the work requires interpreting varied language, extracting meaning from unstructured material or producing a draft that a qualified person can efficiently verify. In the example, summarizing a complex supplier submission might remain worthwhile after the intake and approval process has been clarified.
That is a narrower and more testable proposal than asking AI to “fix onboarding.” Once that need is established, the next design question is how much autonomy the task requires.
Compare against an improved process, not only the old one
A weak comparison tests the existing inefficient process against a redesigned process that also happens to include AI. If performance improves, it attributes the entire improvement to the model.
A more useful comparison separates the contributions:
- Current process: establish the observed starting point.
- Improved process without AI: clarify inputs, ownership and necessary steps.
- Improved process with a bounded AI step: test whether the added capability produces further useful improvement.
Use comparable cases and the same definition of completion. Include checking and correction effort, operating cost, exception handling and the consequences of mistakes. Where a controlled comparison is impractical, document the differences and avoid claiming that AI alone caused the result.
This also improves the AI business case: the proposal must explain the additional benefit of AI after feasible process improvements, rather than taking credit for every change. Any time released still needs a credible connection to a business outcome, as discussed in measuring value beyond time saved.
Make “not yet” a specific decision
A readiness review should not end with a vague request to improve processes. Write a short decision that names the obstacle, the owner and the evidence needed to reopen the AI proposal.
For the illustrative onboarding case, that could read: “Clarify the required submission fields and approval ownership first. Then compare the revised process with and without AI-assisted document summaries. Reconsider the AI step when we can observe its effect on completed cases and review effort.”
Other outcomes may be appropriate: proceed with a tightly bounded experiment while a separate improvement continues, use conventional automation, or stop a proposal whose additional value does not justify its cost and risk. A process does not need to be flawless; it needs enough clarity for the proposed intervention to be evaluated and managed.
The NIST AI Risk Management Framework 1.0 supports examining context before deciding whether AI is appropriate. Its MANAGE 2.1 outcome also includes viable non-AI alternatives when considering how to manage risk. The process-first diagnostic here is my practical synthesis, not a NIST checklist or a certification requirement.
The goal is not to maximize the amount of AI in the business. It is to improve how the business works, with a clear reason for every capability added.
If you are deciding where AI belongs in an existing operation, schedule a consultation to examine the bottleneck, the simpler alternatives and the evidence needed for the next decision.