Having several AI ideas does not mean you have several good first projects.

A manufacturer may be considering predictive maintenance, quality inspection, forecasting or production scheduling at the same time. While each idea can sound worthwhile, the teams involved still have limited time, data capacity and budget.

That makes the first choice important, because a project that is too broad can take months before anyone knows whether the idea is useful. At the same time, one that is too small may be easy to deliver but make little difference to the operation.

A sensible first project sits between those two extremes: it tackles a problem that matters, uses data you can realistically work with, has a clear owner and can be tested without overloading the people who already run the plant.

The aim is not to choose the most impressive idea, but the one with the clearest route from a real problem to a measurable improvement.

1. Which AI use case should you invest in first?

When several ideas are competing for attention, avoid ranking them only by how advanced or exciting they sound.

A company-wide predictive maintenance programme may appear more strategic than a focused quality project still, if the maintenance data is inconsistent across plants. In contrast, if the quality problem is well understood, and the necessary data is already available, the smaller project may be the better place to begin.

A sensible first project usually has four things in common: the problem matters, the data is usable enough to investigate it, ownership is clear, and the delivery path is manageable.

None of that guarantees success, but it gives the team a fair chance to learn something useful without committing more effort than the organisation can support.

2. Is the business issue important enough to justify an AI project?

Before comparing technology options, ask whether the underlying manufacturing problem is important enough to justify the effort.

A project can be technically possible and still be a poor investment if the operational issue is small, rare or already handled well enough with a simpler approach.

Describe the problem without mentioning AI. For example, you might say “This failure causes repeated unplanned stops, and we do not see enough warning to plan maintenance” or “This defect is found too late, creating avoidable rework.”

Then ask what would actually improve if the problem were handled better: would downtime fall, scrap reduce, planners avoid repeated schedule changes, or people spend less time on manual inspection?

If the answer is still unclear, the project needs a better problem definition before it needs an AI model.

3. Who is responsible for solving the issue and measuring the outcome?

Once the problem is clear, identify who owns the operational outcome and who will improve it.

The data or IT team may build or support the solution, but ownership of the result needs to sit with the part of the organisation responsible for the manufacturing problem.

That may mean maintenance and manufacturing for downtime, quality and production for inspection, or planning and supply chain for forecasting.

Clear ownership matters because the project will eventually need non-technical decisions, including what should change, how the output will be used, and whether the result is good enough to continue.

If nobody owns those questions, the work can become a technical exercise that never changes the process it was meant to improve.

4. Do you have the data needed to make the AI use case work?

Having a lot of manufacturing data does not mean the information needed for every project is available or usable.

For predictive maintenance, sensor readings may already exist, but the team also needs reliable information about failures, maintenance events and operating conditions so those signals can be interpreted properly.

The same principle applies elsewhere: images for visual quality inspection need to link to a clear quality result, while forecasting data may need to be understood alongside product changes, promotions, capacity and other factors that affect demand.

So the practical question is not “How much data do we have?” but “What information do we need to understand this problem, and do we capture enough of it today?”

You do not need perfect data; you need data usable enough to test the idea, with gaps understood well enough to plan around.

5. What business value could the AI use case realistically create?

Before turning the expected benefit into a financial estimate, describe what should improve in the operation.

A predictive maintenance project might aim to reduce disruption from one recurring failure, a quality project might focus on detecting one defect earlier, and a forecasting project might aim to reduce repeated production-plan changes for a specific product group.

Once that change is clear, you can assess what it affects, such as lost production time, scrap, rework, manual effort, capacity, or service levels.

Keep the estimate realistic and focus on the part of the problem the project can genuinely influence, because an AI model cannot remove every cause of downtime or every forecasting error.

A narrower, credible estimate is more useful than a large theoretical benefit that depends on everything working perfectly.

6. What technical work needs to happen before the project can start?

Once the problem and data are clear, the technical work becomes much easier to scope.

You may need to connect an existing data source, clean up labels, create a secure way to access images, make production and maintenance records easier to link, and decide where the model will run and how its output will reach users.

That does not automatically mean buying a new platform or replacing existing systems. Often the more practical question is how to use the systems and data already in place well enough to test the idea.

The key is to identify dependencies early, because a project that needs months of integration before anyone can test the core idea may be a poor first choice when another can be investigated with much less preparation.

7. How much time will the project need from your plant, IT and data teams?

AI projects need time from more than just the technical team.

Plant experts may need to explain the process, review examples, and test whether the output makes sense. In contrast, IT may need to arrange access, security, and integration, and data teams may need to prepare and assess the information before modelling begins.

Because that work usually happens alongside normal responsibilities, treat it as part of the delivery effort rather than assuming it will be available.

When comparing projects, ask which teams need to contribute, how often and for how long, because an idea that depends on scarce specialists across several plants may be harder to move forward than one that can be tested with a focused local team.

A manageable first project should create useful learning without pulling too many people away from day-to-day operations.

8. Will plant teams actually use the AI output in their day-to-day work?

A technically strong result only matters if it fits into the process people already follow.

If a model predicts that a machine is likely to fail, someone still needs to see the warning, understand how confident it is and decide whether maintenance can act now or must wait for a planned stop.

The same applies elsewhere: a quality alert may need to trigger an inspection or product diversion, while a better forecast only helps if planners can use it to change a decision.

That is why the people who will use the output should be involved before the project starts, as they can explain practical constraints not obvious in the data.

If the project requires a completely new way of working, include that effort in the comparison rather than assuming adoption will happen automatically.

9. How should you compare different AI opportunities?

Use the same questions for every idea so the comparison is fair.

• How important is the operational problem?
• What measurable improvement could the use case create?
• Is the necessary data available and understood?
• How much technical preparation is required?
• How much time will plant, IT and data teams need to contribute?
• Is there clear ownership of the outcome?
• Can the output fit into day-to-day work?
• Can you test the idea at a useful scale without committing to a full rollout?

You do not need a complicated scoring model; the purpose is to make the trade-offs visible.

A project with a large potential benefit but major data gaps may belong later in the roadmap. In contrast, another with a smaller benefit but clear data, ownership and a practical test may be a better first project because it can produce useful learning sooner.

10. What makes an AI use case a sensible first project?

A sensible first project is focused enough to manage but important enough to matter.

It usually targets a specific problem rather than an entire function, so one recurring failure on one machine type is easier to test than predictive maintenance across every critical asset, one quality defect is easier to investigate than automating every inspection step, and one product family may be a better forecasting test than rebuilding the whole planning process.

The project should also have a clear baseline so the team can compare the result with what happens today.

Most importantly, the people responsible for the process should be able to explain what they would do differently if the project worked, because that gives the team a concrete test of whether the result is useful rather than simply technically impressive.

11. When should you improve the data or process before investing in AI?

Sometimes, the right outcome of the assessment is to wait and improve the data or process first.

You may find that failure events are not recorded consistently enough for predictive maintenance, quality labels differ between plants, or the current process is so unclear that nobody can explain where an AI output would fit.

Those findings are useful because they show what needs attention before a larger investment.

The first phase may therefore involve improving event recording, agreeing on a KPI definition, connecting two existing sources, or clarifying the operational process.

This is still useful progress because it identifies what needs to change before you commit more time and budget to the AI project.

12. Does the financial case justify the investment?

Once you have a focused idea, compare the expected benefit with the full cost and effort required to deliver it.

That means looking beyond model development to include data preparation, integration, infrastructure, security, plant involvement, ongoing support and any process change needed to use the output.

Then compare that effort with the operational improvement you expect, asking how much downtime could realistically be avoided, how much rework or manual effort could be reduced and what part of the financial benefit can reasonably be linked to the project.

The answer does not have to be exact at the start, but the assumptions should be visible.

If you already have a defined idea, the AI Profitability Calculator can help structure that comparison before you commit to delivery.

13. What should you do once you have shortlisted an AI use case?

Do not move straight from a shortlist to a large implementation; use the next step to test the assumptions that matter most.

That may mean checking whether the required data is good enough, whether the model can identify the pattern you care about or whether the plant can use the output in time to change the process.

Agree what the test needs to prove before it begins, keeping the scope narrow enough to learn quickly but realistic enough that the result means something in the real operating environment.

At the end, review the technical and operational results together: did the team get information early enough, did people trust it, could they act on it, and did the process improve compared with the starting point?

Those answers should determine whether you scale, adjust the idea or stop.

14. What a practical first AI project looks like in practice

Imagine a manufacturer that wants to explore predictive maintenance across several plants.

The broad ambition may be sensible, but it is too large for a first test, so the team chooses one recurring failure on one machine type at one plant.

Maintenance already knows the failure causes disruption, relevant machine data is available, service records provide enough history to investigate what happened before previous failures and the people who would use an early warning are involved from the beginning.

The first question is not “Can we build predictive maintenance for the group?” but “Does the available information contain a useful signal before this specific failure, and would the warning arrive early enough for maintenance to act?”

If the answer is yes, the team can test the process in the real environment and measure whether it reduces disruption; only then does wider rollout become the next decision.

The same approach works for quality and forecasting: choose one defect, one product family, or one recurring problem; learn what the data can support; test the result with the people who will use it; and measure what changes in the operation.

A practical first AI project does not need to prove everything; it needs to prove enough to make the next investment decision with more confidence.

What to do next

A strong first AI project should matter enough to be worth doing, but be focused enough to test without placing too much demand on the organisation.

Comparing opportunities against the same criteria can make that choice much clearer: the importance of the problem, the quality of the available data, ownership, delivery effort, expected improvement and how the output would be used in practice. You can then test the strongest candidate at a sensible scale before considering any wider rollout.

Already comparing AI ideas?

Use the AI Profitability Calculator to estimate the potential return of a defined AI project before committing more time and budget.

TRY THE AI PROFITABILITY CALCULATOR