How to find the AI-ready workflows in your business

The difficulty with asking for AI opportunities

When I ask people in a manufacturing business where they think AI might help, I usually get suggestions quite quickly. Somebody spends too long preparing quotations, the production team is forever updating a spreadsheet, or a manager is tired of searching through emails for information that ought to be available somewhere else. These are useful starting points because they identify activities that people experience as difficult. But that is not yet a list of AI opportunities. What people tend to describe first is the inconvenience they encounter, and the cause of that inconvenience may be somewhere else entirely.

A quotation that takes two days to prepare may involve only twenty minutes of actual drafting. The remaining time might be spent waiting for a price, clarifying a specification, checking whether production can meet the requested delivery date, or getting approval for an unusual commercial commitment. An AI system might help produce the document more quickly, but that would have little effect on the time the customer waits if the delay occurs elsewhere. Before selecting a technology, I want to understand what is happening between the initial request and the completed result. The work is the unit of investigation, rather than the application somebody happens to be using.

Following one piece of work

The most useful place to begin is often a specific example of work that has recently been completed. I prefer to follow a real customer enquiry through the business rather than rely solely on a general description of how enquiries are supposed to be handled. The formal process has its place, but it may omit the small adjustments, informal conversations and exceptions that allow people to get the job done. An employee can explain the official procedure perfectly well and then, when we look at a recent case, reveal that a particular step is routinely bypassed because it no longer serves a useful purpose.

Following an actual case also helps establish boundaries. We can identify what caused the work to begin, what counted as a satisfactory result, which people were involved and where information moved between them. In a manufacturer, that might mean following an order from receipt through technical review, production planning and release, or examining a non-conformance from its first report to the decision that it has been resolved. The scope should be large enough to expose the handovers but small enough that the people involved can explain what happened without reconstructing an entire department’s history.

I am particularly interested in the difference between what somebody does and what they are waiting for. Employees can be busy throughout the day while individual pieces of work spend most of their lives stationary. A job may wait for missing information, an approval, a production slot or a response from a colleague who is dealing with other priorities. If we only measure the time spent carrying out each task, we may conclude that the process is efficient while customers and colleagues continue to experience long delays. The time between activities often tells us as much as the activities themselves.

Looking at the exceptions

Routine cases are useful for understanding the basic sequence, but exceptions often reveal how the organisation really works. What happens when the customer changes a specification after a quotation has been prepared? How is a production order handled when a material is unavailable? Who decides whether a non-conforming item can be reworked, and what evidence do they need? These situations expose the points at which employees have to interpret information, negotiate priorities or exercise authority. They also show which systems and procedures are sufficiently useful to support the work, and where people rely on personal experience to compensate for gaps.

The people who perform the work are essential to this investigation, alongside the managers who oversee it. Somebody responsible for entering an order may know that the same customer details are typed into two systems. A production planner may maintain a private spreadsheet because the official schedule does not reflect the decisions made in the morning meeting. A quality engineer may know that an apparently complete incident record does not tell the whole story. None of this means the employees are doing something wrong. These local arrangements may be sensible responses to the circumstances they face, and removing them without understanding their purpose could make the work harder.

This is also where a little evidence is useful. I am looking for the frequency of these exceptions, the time they consume, how often information needs correcting and whether they affect delivery, quality, cost or customer confidence. The numbers need not be perfect at the outset. Even a small sample of recent cases can help distinguish an irritation that happens occasionally from a persistent constraint on the business. Without that distinction, it is too easy to prioritise whichever problem was described most enthusiastically in the first meeting.

Separating different kinds of activity

Once the work is visible, I find it helpful to distinguish the different kinds of activity taking place. Some steps involve moving or recording information according to clear rules. Others require interpreting documents, recognising patterns or assembling evidence from several sources. Some involve decisions where the consequences of getting it wrong are significant, and where a named person must remain accountable. These activities may sit alongside one another in the same workflow, but they should not automatically be treated in the same way.

Consider the handling of a supplier quality complaint. Recording the date, supplier, part number and relevant documents is largely a matter of structured information capture. Checking whether all required fields are present might be straightforward to automate. Reviewing previous complaints for similar symptoms may benefit from AI-assisted retrieval and comparison, provided the underlying records are sufficiently reliable. Deciding whether material can be used, quarantined or returned involves technical, commercial and sometimes safety considerations. An AI system might help assemble the evidence, but that is different from authorising the decision. Treating the entire activity as one candidate for automation obscures these distinctions.

The same applies to information quality. A language model may be capable of extracting details from a customer drawing, but it still needs access to the right drawing and a way to establish that the revision is current. If the business cannot reliably identify the authoritative version, adding AI may increase the speed at which uncertainty spreads. This draws my attention to the information used at each stage: where it originates, who maintains it and how employees decide whether to trust it. These are practical questions about doing the work properly, rather than preliminary technical requirements to be delegated entirely to IT.

Choosing the intervention

By this point, several possible interventions may be apparent, and AI will be only one of them. Some work may no longer be necessary. A duplicated approval could be removed, or two reports might be consolidated because they contain essentially the same information. A recurring delay might be reduced by clarifying who has authority to make a decision. A spreadsheet might be replaced by a shared structured record, or a routine transfer between systems might be automated. Where people spend time reading and comparing large volumes of information, AI may provide genuine assistance. The point of the investigation is to choose between these possibilities with some understanding of what each would change.

An impressive demonstration is a poor basis for ranking improvement opportunities. The best initial project may be a modest change to an awkward handover, particularly if it removes repeated effort and makes information more reliable. Equally, there may be a valuable AI application hidden inside an otherwise ordinary workflow, such as helping an engineer locate relevant evidence from previous investigations. What matters is whether the proposed intervention addresses a real constraint, whether the required information is available, and whether the business can judge the result reliably.

For an AI-assisted activity, the boundary of responsibility needs to be explicit. What is the system being asked to produce? What evidence should accompany its answer? How will a user recognise when the information is incomplete or uncertain? What must be checked before anybody acts on the output? These questions should be answered before the business begins relying on the system. They are especially important in manufacturing, where a plausible but incorrect summary of a technical requirement could have consequences far beyond the time saved in preparing it.

Testing whether anything improves

A small trial should tell us more than whether the technology can perform a task under favourable conditions. It should establish whether the work improves when the proposed change is introduced. If the aim is to reduce the time required to investigate a quality problem, we need some understanding of the existing effort and delays. If the aim is to make quotations more reliable, we should examine rework, missing information and the frequency of clarification requests. The measures should follow the business problem rather than the capabilities of the tool.

The trial also needs ordinary, awkward cases, rather than only carefully selected examples. A system that performs well when all the documents are complete may be less useful when a customer has supplied an ambiguous specification or when records disagree. In these situations, a good outcome may be that the system identifies the uncertainty and asks for a human decision. That is still valuable if it helps the business reach the right conclusion with less effort and better evidence.

The result of this work is not necessarily an AI implementation plan. It may be a clearer understanding of where time is lost, which information is unreliable, where judgement is required and which changes are likely to matter. In my experience, that is a much stronger basis for investment than beginning with a list of things AI might be able to do. The organisation can then choose a limited intervention, test it against real work and expand only when there is evidence that it helps.