Last issue, we talked about Operational Readiness: defining the problem clearly and making sure the process is stable enough to measure.
That is the right place to start. A fuzzy problem statement will sink an AI project before the technology ever has a chance to help.
But even a well-defined problem can stall for a simpler reason: the operation does not leave a reliable data trail.
This is where the next readiness category comes in: Data Foundation.
Plain English version: before AI can predict, optimize, flag, summarize, or recommend anything useful, the business has to know whether the right information is being captured, whether people trust it, and whether it exists somewhere besides paper forms, tribal knowledge, and five versions of the same spreadsheet.
AI does not fix messy operational data.
It usually makes messy operational data more expensive.
Data Foundation has two jobs
When I talk about Data Foundation, I am mainly talking about two things.
Data integrity: do people trust the numbers?
If production says downtime was 42 minutes, maintenance says it was 90 minutes, and the supervisor says the real issue was waiting on material, which record is true?
If quality tracks defects one way in the ERP, another way on a paper form, and another way in a spreadsheet used for the Monday meeting, which number does leadership make decisions from?
Data integrity does not mean every field is perfect. It means the business has enough confidence in the record to use it for decisions.
Digital capture: is the relevant information captured digitally where the work actually happens?
A lot of manufacturers have data, but not always the kind AI can use cleanly. The critical details may be in handwritten inspection sheets, verbal handoffs, photos on somebody's phone, notes in a supervisor's notebook, or tribal knowledge that never gets recorded at all.
If the process you want to improve does not produce a trusted digital trail, your first AI project is not really an AI project. It is a data cleanup and capture project with AI sitting downstream.
The better first question
Here is a common version of the trap.
Leadership asks: "Can AI predict which jobs are most likely to run late?"
That sounds like an AI question.
But the better first question is: "Do we have a reliable record of why jobs ran late in the past?"
Was it machine downtime? Missing material? Rework? Labor availability? Bad estimates? Customer changes? Waiting on approval? A supplier delay?
If those causes are captured inconsistently, the model has nothing solid to learn from. It may still produce an answer, but the answer will be dressed-up guesswork based on incomplete history.
The same thing happens in quality.
A manufacturer may want AI to flag incoming parts that are likely to fail inspection. Reasonable use case. But then you look at the data trail and find that inspection results live in three places: the ERP record, a paper checklist, and a spreadsheet the quality lead updates when there is time.
Some defects are coded by category. Some are described in free text. Some are recorded as vendor issues. Some are handled by phone and never make it into the system.
Now the AI question changes.
It is no longer, "Can we predict defects?"
It is, "Do we have a consistent definition of a defect, a reliable record of inspection outcomes, and a clean way to connect those outcomes back to the part, supplier, batch, and process step?"
That is where the real work starts.
Bad data does not stay quiet
The risk with AI is not just that messy data produces weak results.
The bigger risk is that messy data produces confident results.
A spreadsheet error is usually visible to somebody close to the work. An AI-generated recommendation can look more polished than the data deserves.
That is why Data Foundation belongs early in the readiness framework.
Not because every business needs a data warehouse before doing anything useful with AI. That is overkill for most SMBs.
The point is narrower and more practical: before you automate judgment, make sure the record underneath that judgment is good enough to deserve automation.
If it is not, slow down.
Do not buy the tool yet.
Find the data trail first.
Where AI can still help before deployment
This does not mean AI has to wait until the data is perfect.
One of the best early uses of AI is helping inspect the mess before you build on top of it.
AI can help a team:
summarize ERP exports and surface missing fields
compare defect labels across systems and spot inconsistent naming
group similar free-text notes into cleaner categories
identify duplicate or conflicting records
turn paper forms or PDFs into structured review material
compare supervisor notes against formal production records
build a first-pass data inventory for one process
That work is not glamorous, but it is valuable.
It can help you answer a practical question: "What do we already know, what do we think we know, and what are we not capturing at all?"
But there is an important caveat.
AI can help inspect the data foundation. It cannot own it.
Somebody in the business still has to decide what counts as downtime, what counts as a defect, which system is the source of truth, who maintains the fields, and what gets captured at the point of work.
Those are operational decisions, not software settings.
A practical checkpoint
Pick one process you are tempted to improve with AI.
Not the whole company. One process.
Incoming inspection. Preventive maintenance. Purchase order approval. Production scheduling. Customer intake. Quote review.
Then identify the three fields you would need to trust before automating, predicting, or recommending anything.
For incoming inspection, that might be:
supplier
defect type
inspection outcome
For maintenance, it might be:
asset ID
downtime reason
corrective action
For scheduling, it might be:
promised ship date
actual completion date
reason for delay
Now ask three questions about each field:
Where is it captured?
Who maintains it?
Do people trust it?
If the answer is clear, you may be closer to an AI-ready process than you think.
If the answer is "it depends," "ask Bob," or "we have a spreadsheet for that," you have found the work that needs to happen first.
That is not failure. That is readiness work.
I am also building something around this readiness framework now. More on that soon.
As always, no hype, no vendor pitches. Just what I have seen working in the field.
Reply with one process and the three fields you would need to trust. I will tell you whether the next step is cleanup, capture, or problem redefinition.
— Chris
Idaho AI Strategies · Boise, ID