Start with a decision, not a demonstration
An impressive AI demonstration does not establish that an operation is ready to use it. The starting question is what decision or task needs to improve, who owns it and what a better result would look like. Without that definition, a deployment can produce more information while leaving the original problem untouched.
The sequence I use begins with understanding the process, improving it and then selecting the appropriate automation. This does not require waiting for perfection. It requires enough clarity to know which parts are stable, which exceptions matter and where a person must remain responsible. The technology should support an understood operating need.
Map the real process
Begin with the demand that triggers the work and the output that the next customer needs. Identify the steps, handoffs, decisions and data used along the way. A SIPOC can set the boundaries; a value stream view can expose waiting and rework. Confirm the map with the people who perform the process rather than accepting the documented procedure as a complete description.
Record exceptions separately. Which inputs arrive incomplete? When does the team override the normal sequence? Which approvals depend on knowledge held by one person? These questions reveal both improvement opportunities and limits on automation. A process that looks straightforward in a workshop can behave very differently when demand changes or an unusual case arrives.
Stabilise what the technology will depend on
Remove avoidable steps and clarify the remaining ones. Agree the expected method, ownership and response when the standard cannot be followed. Let the team help write and test the standard. A document that nobody uses is a weak foundation for a system expected to reproduce the same behaviour at scale.
Examine the data at the point of creation. Define the fields that matter, how they are recorded and what missing or ambiguous entries mean. Compare records with actual work. Correct a recurring recording problem in the process rather than relying entirely on a later cleaning exercise. Clean data that cannot be maintained is a temporary advantage.
Choose a baseline that reflects the intended benefit. If the problem is waiting, measure elapsed time and queue age. If the problem is decision quality, agree how a sound decision will be recognized. Include measures that would reveal harm, such as avoidable rework or an increased review burden. Speed alone can conceal a poorer outcome.
Pilot with a clear boundary
Select a bounded use case where the result can be evaluated. An assistant might summarize maintenance notes, prepare an initial problem statement or highlight incomplete inputs. Make the output's status explicit: a draft, suggestion or decision support item should not silently become an approved instruction. Set access permissions and avoid using confidential material in an unapproved service.
Test representative cases and difficult exceptions. Compare the output with the agreed baseline and have the responsible people review where it is useful, misleading or incomplete. Record failure conditions and define when the process returns to a manual route. The pilot should teach the team how to operate the system, not just whether it can produce a convincing answer.
When the evidence supports expansion, assign ownership for monitoring, changes and incident response. Review the process whenever the work or underlying data changes. Continuous improvement and AI can reinforce each other: one makes the operation understandable and controllable; the other can extend what a well-designed operation is able to do.