Use factory data to answer a production question.

Start with the decision, then work backward to data

“Use our factory data” is not a project boundary. Name the decision, its owner, the time available to act, the cost of a wrong answer, and the measure that should change. Examples include choosing which recurring stop to investigate, deciding whether to release an order, or identifying a process condition that raises defect risk.

This framing prevents two common failures: collecting everything without a use case and building a dashboard that reports a problem after the decision window has closed. NIST describes smart-manufacturing analytics as a feedback loop that senses, models, analyzes, communicates, and supports action.

• Decision and accountable owner
• Required lead time and refresh rate
• False-positive and false-negative cost
• Baseline, target, and verification window

Create context across machines, orders, products, and time

A PLC tag has little meaning without asset identity, state, unit, sampling rule, and timestamp. A quality result is difficult to explain without the material lot, recipe, machine condition, operator action, and production order that preceded it. Build a small semantic layer that connects these identities before calculating advanced metrics.

Keep raw facts separate from derived classifications. Preserve source, original timestamp, timezone, unit, transformation version, and quality flag. When clocks drift or counters reset, record the correction instead of silently rewriting history.

• PLC and sensor states, alarms, counts, cycles, and setpoints
• MES orders, routes, product, recipe, and genealogy
• ERP demand, due dates, inventory, and commercial priority
• CMMS work, confirmed faults, replaced parts, and inspection findings
• Manual observations with author, time, and controlled categories

Audit data around the decision, not in the abstract

Completeness is contextual. Missing vibration data may not affect a schedule decision, while one unsynchronized order timestamp can invalidate a lead-time analysis. Test coverage by asset and operating regime, identity joins, units, duplicates, counter behavior, clock alignment, and whether labels represent confirmed events.

Profile data by shift, product, machine state, and change period. A model trained mostly on steady daytime production can fail during startup, cleaning, maintenance, or low-volume products even when its overall accuracy looks strong.

Match the analytical method to the question

Use descriptive analysis for “what happened,” diagnostic analysis for “why,” predictive methods for “what is likely next,” and simulation or optimization for “what should we try.” Do not use machine learning when a stable rule, control chart, or direct calculation answers the question more reliably.

When AI is justified, compare it with a simple baseline, test unseen time periods, expose confidence, and monitor drift. Correlation can generate a candidate explanation; it does not establish a physical cause. Use domain review, controlled trials, and system simulation before turning a pattern into an intervention.

1. Describe

   Reconstruct the event, loss, and operating context.

2. Diagnose

   Test competing mechanisms against synchronized evidence.

3. Predict

   Estimate a future state and show uncertainty.

4. Simulate

   Test how a proposed action propagates through the system.

5. Verify

   Compare the real outcome with the prediction and update the model.

Deliver an operating loop, not a data product

Every insight needs a response rule: who receives it, what evidence they see, what action is allowed, when it expires, and how the result is captured. Track decision latency, alert acceptance, false signals, prevented loss, and whether the recommendation changed the outcome, not dashboard views.

Begin with one line and one consequential decision. Reuse connectors and definitions only after the pipeline, analysis, response, and verification loop works. That is how analytics becomes continuous-improvement infrastructure rather than an expensive reporting layer.

Five, six or seven data-quality dimensions need a named source

The UK government’s data-quality guidance uses six DAMA UK dimensions: completeness, uniqueness, consistency, timeliness, validity and accuracy. Its authors describe the list as non-prescriptive. Choose checks that fit the records and decision in question rather than treating a five- or seven-item search question as a mandatory manufacturing standard.

Make the distinction concrete. A production timestamp can pass its required format and still record the wrong event time. It is valid in format but inaccurate for the intended clock. A complete record may contain duplicates; a unique record may arrive too late for dispatch. A five-Cs label without an author is too ambiguous to supply a reliable checklist. Ask which model is meant, then retain the checks the actual decision needs.