Buyer resource
Manufacturing Data & AI Readiness Assessment
A manufacturer is ready for AI when five layers hold: machine data is captured automatically, stored with production context, trusted by the people who would act on it, hosted on infrastructure that can serve it, and owned by someone accountable for decisions made with it. Most plants discover they are two layers short — which is fixable, and cheaper to fix before the AI project than during it.
Published · Last reviewed by Geek Engineering senior engineering review.
Layer 1: Capture — does the data exist at all?
Paper logs and end-of-shift spreadsheets are not a data foundation; they are a memory of one.
- Are the machines involved in your use case connected, or do their PLCs hold data no one collects?
- Is capture automatic, or does it depend on operators writing numbers down?
- Is the sampling frequency meaningful for the physics involved (a once-a-minute reading cannot explain a two-second event)?
Layer 2: Context — can the data answer questions?
Raw sensor values without context correlate with nothing. Check whether your stored data carries:
- Product, recipe, or job linkage at the time of each reading
- Machine state: running, changeover, starved, faulted
- Shift, crew, and material lot where these plausibly matter
- Timestamps that are actually synchronized across sources
Layer 3: Quality and trust
Ask the uncomfortable question: when the dashboard and the supervisor disagree, who does the plant believe? If manual corrections, known-bad sensors, or 'that counter has always been wrong' are part of plant folklore, AI built on that data will automate the distrust. Fixing specific known-bad signals is usually a bounded, unglamorous project — and a prerequisite.
Layer 4: Infrastructure
- Storage: is history retained long enough to cover seasonal and product-mix variation?
- Access: can an analysis tool query the data without a human export step?
- Network and security: is there an approved path for OT data to reach where analysis happens?
- Latency: does the use case need daily summaries or near-real-time signals?
Layer 5: Organizational readiness
Technology readiness without organizational readiness produces impressive dashboards nobody acts on. The test: name the person who will change a decision based on the AI output, and the process that lets them. If neither exists, start there — a pilot with a named decision-owner beats a platform with none.
Scoring yourself honestly
Score each layer 0–2 for the specific use case you have in mind (not for the plant in general — readiness is use-case-specific). A total of 8–10 means a pilot can start now; 5–7 means a bounded foundation project comes first; below 5 means the honest first step is connectivity and context, and any AI proposal you receive should be treated with suspicion.
Readiness, measured against observable criteria
| Dimension | Not ready | Partly ready | Ready |
|---|---|---|---|
| Outcome recorded | The thing you want to predict is not captured anywhere | Recorded inconsistently or on paper | Captured automatically with a timestamp |
| History depth | Weeks | Months, few occurrences of the outcome | Long enough to contain many occurrences |
| Correlation across systems | Clocks disagree, no shared identifiers | Some systems align | Common time base and shared part or batch identifiers |
| Resolution | Shift totals only | Hourly | Event or sub-second where the process demands it |
| A decision that would change | Nobody would act differently | Interest, no owner | A named owner who would change what they do |
Key takeaways
- Readiness is use-case-specific: score capture, context, trust, infrastructure, and ownership for one decision.
- Context is the layer most plants miss — values without product and state linkage answer nothing.
- Known-bad signals must be fixed before modeling; AI amplifies data culture, good or bad.
- A named decision-owner matters more than any platform choice.
Related questions
What data foundation is required before industrial AI?
Automatic capture from the machines in scope, storage with production context (product, state, time), enough clean history to represent normal operation across your real variation, and an access path for analysis. That foundation is buildable in bounded scope — which is exactly what a well-designed pilot does first.
How much historical data do we need?
Enough to cover the variation the model must handle: product mix, seasons, material lots, and the failure or quality events you care about. For anomaly detection on stable processes that can be weeks; for predicting rare events it can be much longer — or the honest answer is to start collecting now and run analytics that do not require rare-event history in the meantime.
Do we need a data lake or new platform first?
Not to start. A bounded pilot can run on a well-configured historian or a modest time-series database. Platform decisions made before a single use case has proven value tend to be oversized and under-informed; let the first pilots teach you what the platform must actually do.
Our data is in silos — historian, quality system, ERP. Is that a blocker?
It is a constraint, not a blocker. Most first use cases need only two or three sources joined for a specific question, which targeted integration can deliver without a plant-wide unification program. Plant-wide integration is a roadmap item that early use cases fund and justify.
Prefer to talk this through?
Send a short brief — objective, equipment, timeline — and a senior engineer will respond with questions and an honest fit assessment.
Get a Quote