Manufacturing AI With Messy Factory Data: Minimum Data Needed for a First Decision

TL;DR

• You do not need every plant dataset clean to make one defensible AI-assisted decision. You need trustworthy evidence for the specific decision you want to make.

• Start with one choice, such as whether to move order B ahead of order A on one packaging line during the next shift. Name the planner who owns the decision.

• Sort inputs into required, useful, and unnecessary for that choice. Order details, line availability, applicable constraints, timestamps, and source records are required. Other plants’ data may be unnecessary.

• Set plant-specific freshness rules and stop when required evidence is stale, missing, or conflicting. A planner verifies the inputs before approving a schedule change. Local mappings suffice while record ownership stays clear. Repeated disputes across systems or sites call for shared semantic context.

How much factory data does one scheduling decision need?

Plantwide data readiness projects cover a much broader problem than a same-shift scheduling exception. Such projects may standardize records across products, equipment, and sites. If you need to reorder two jobs on one packaging line, you can begin with evidence for that line and shift. You do not need a clean history of every machine before asking whether the change is feasible.

Two orders are queued on the same packaging line for the next shift. Order B is due before A, but swapping them only works if both jobs, the changeover, and existing commitments fit the available hours. In this hypothetical plant, ERP holds the order details and MES records line status. A stale line-status event stops the proposed swap, even if the rest of the records look complete.

Defining the one decision before touching any data

Define the proposed schedule change and its approver before assessing the data. In this hypothetical, a planner proposes running order B before order A on one packaging line during the next shift. The planner owns the proposal, and the shift lead approves its release if the plant has assigned that role approval authority. That scope tells you which records must be checked and who can resolve an exception.

For this decision, the planner needs to know whether the line can run both orders in the proposed sequence without violating capacity, setup, material, or quality constraints. A due date alone cannot establish that the sequence is feasible. The finite scheduling versus APS guide covers when a proposal needs a separately validated finite scheduling calculation. Records from other plants do not help answer this one-shift question unless they govern a shared constraint.

The minimum viable evidence checklist

Required evidence must show whether order B can run before order A on the chosen packaging line during the upcoming shift. A named planner must own the recommendation, and an authorized approver must own its release. ERP records must supply stable order and product IDs, due dates, quantities, and lot IDs if lot identity affects scheduling or a constraint check. The plant must identify each packaging operation, its eligible line, and the work already assigned to the proposed interval in MES or another designated operational record. Current line status and a capacity calculation must show that both orders, their changeover, and already committed work fit within the available shift time. SAP’s process-order scheduling lesson shows how finite scheduling prevents two orders from occupying the same resource at once and how operation dependencies affect the sequence.

Required evidence must support a repeatable constraint check. The planner checks setup rules, material release, and quality holds for both orders. Source-system and record IDs, timestamps with time zones, and consistent units let another reviewer reconstruct the calculation. A line-status value without a current event time cannot establish that the slot is available.

Useful evidence sharpens the estimate when it is available. Recent run rates and measured changeover times can refine the capacity calculation. An operator note may reveal a line restriction, and staffing matters if a qualified operator is needed this shift. If any of those facts decides whether B can run, move it to the required list.

Unnecessary data stays outside this one-line decision. The planner does not need every historical sensor reading, unrelated quality records, or other plants’ full production histories to compare these two orders. An enterprise-wide ontology is also unnecessary if the plant can reliably map each ERP order to its MES operation and the named packaging line. That local mapping still needs an owner who can verify it when records disagree.

Which records govern the scheduling decision?

Before an AI-prepared scheduling recommendation reaches a planner, assign an owner and a governing record to each required field. For the proposed order sequence, ERP governs order IDs, quantities, and due dates. MES or a designated operations record governs line status and current work. The designated quality record governs holds and releases. The approved plant calendar governs shift hours, while the plant's designated routing or equipment record governs line eligibility. The JD Edwards scheduling overlay guide shows how one ERP deployment can define record ownership without replacing its existing systems.

The plant must set a maximum record age for each required field against the time of the proposed change. A due date may tolerate an older update than line status for a change in the upcoming shift, but the plant must set both limits. Each required input should carry its source record ID, event time, retrieval time, time zone, and units where applicable. A present value does not qualify as current evidence if its source event exceeds the plant’s limit.

The assigned record owner resolves disagreements before the planner uses a disputed value. If ERP and a dispatch copy show different due dates, the order owner checks the ERP record and logs any correction or authorized override. If MES shows an available line while the line lead reports a stoppage, the planner holds the recommendation until the operations owner confirms status in the designated record. A quality hold remains in force until the quality owner records its release.

AI does not clean bad data or reconcile conflicting records. When a required input is missing, stale, or disputed, the recommendation stops and goes to its named owner for verification. The planner can then review the proposed sequence against confirmed line status, holds, material availability, and approved constraints before authorizing any production change.

The stop/go test and the auditable decision record

In the hypothetical packaging shift, the decision layer proposes moving order B ahead of order A because B is due earlier. MES shows an apparent two hour opening, but its equipment availability event is older than the plant permits for a change in the upcoming shift. The opening alone does not establish that both orders and their changeover fit. The recommendation is no go for release. The planner keeps the current schedule and asks the line status owner to verify whether the slot remains available.

The decision becomes go only after the line status owner verifies availability and the planner confirms that both orders, committed work, and the changeover fit the shift. The planner must also verify material release, applicable setup rules, and the absence of a quality hold. The planner then submits the verified sequence to the authorized shift lead for approval before anyone changes the released schedule. If availability remains uncertain or a quality hold conflicts with the proposal, the planner leaves the existing schedule in place and escalates to the responsible owner. The scheduling exception routing guide covers how a plant can assign approval and escalation rights for such cases.

The decision record should preserve the order IDs, proposed and baseline schedule versions, constraints considered, and the final go or no go outcome. For each input, log its source record, version, event time, retrieval time, and freshness check. Record missing or conflicting values, any human override, the approver’s name and approval time, and the reason for the decision. If the authorized shift lead approves a change, retain the ERP or MES transaction reference and the prior schedule version. The plant's rollback procedure must identify who can restore that version if the approved change cannot proceed.

A service account should read only the approved fields needed to prepare the recommendation. Only an authorized account may write an approved change to ERP or MES, and the write must be traceable to the shift lead's approval.

When does scheduling need ISA-95 or shared semantic context?

For a decision on one packaging line, a local mapping can connect ERP order B and item family X to the MES pack operation and resource PKG-02. These identifiers are illustrative. If a named owner maintains the mapping, the planner can use it to find the records needed to consider running B ahead of A. The mapping does not confirm available capacity or a lot’s quality status.

Shared semantic context becomes useful when a decision spans lines or plants with different equipment names, units, or routings. When ERP and MES repeatedly assign different meanings to equipment, products, process steps, or events, a governed hierarchy and shared definitions give each system a consistent reference. Siemens’ ISA-95 explainer describes the models and terminology used to structure information exchanged between ERP and manufacturing operations systems. The shop floor guide to ISA-95 and industrial ontologies covers that broader architecture.

Humble sits downstream of those mappings and existing ERP and MES records. It can prepare an evidence-backed recommendation for the authorized planner, but it does not build the hierarchy or correct stale source data.

How does Humble support AI scheduling alongside ERP and MES?

Humble fits after the plant has mapped and checked the records needed for a scheduling decision. As a decision intelligence layer, Humble can use contextualized ERP orders and MES execution records to prepare a recommendation for a planner, with the relevant evidence and constraints available for review. ERP retains authority over order details, and MES remains the source for shop floor status. Humble does not clean conflicting data, build an ontology, or replace the infrastructure that connects those systems.

For the packaging-line decision, Humble could show a proposed sequence beside the line capacity, changeover time, material release, and quality status it used. The planner can describe a plant-specific constraint in plain language, then check the resulting rule against approved policy. If line status is stale, the proposal waits. After the operations owner confirms availability, Humble can revise its proposal when a verified constraint changes and retain the reason; the planner reviews the evidence, and the authorized shift lead approves release. A planning tool with equivalent evidence and approval controls could serve the same role.

Book a Call with Humble

Bring one scheduling or quality decision to a call with Humble. Use the discussion to identify the decision owner, required records, and conditions that would stop a recommendation.

See If Humble Fits Your Floor

If you want to check whether your plant has enough evidence for a first scheduling decision, take Humble’s fit test. Use one specific decision, such as reordering two jobs on one line, to assess the fit.

Stay Current on Manufacturing AI

Get practical guidance on factory data and AI-assisted decisions in the Humble newsletter.

Frequently asked questions

Can AI start if factory data is messy?

Yes. You can start with one bounded decision if its required records are current, traceable, and checked by an authorized person. A provisional recommendation must not change the schedule when a required field is missing or disputed.

What is the minimum data for one scheduling decision?

To decide whether order B can run before order A on one line, you need the order IDs, due dates, quantities, line eligibility, available capacity, competing work, and applicable material, setup, and quality constraints. Each required record also needs a source, timestamp, and consistent units. Name the planner and authorized approver. Check the proposed sequence against finite capacity rules so both orders and their changeover fit.

Who owns the stop or go call?

The planner owns the proposal, and the plant's authorized shift lead makes the release decision in this example. That person checks current line status and holds against the proposed schedule. If required evidence remains stale or conflicts with its designated source, the approver leaves the existing schedule in place and routes the exception to its owner.

When does a plant need ISA-95 instead of a local mapping?

A local mapping can suffice when one plant can reliably connect its ERP order, MES operation, and equipment ID with clear ownership. When multiple lines or sites repeatedly disagree about equipment names, units, or process steps, use a governed hierarchy and shared definitions; the ISA-95 shop-floor decision guide explains how that context supports a decision. ISA-95 does not validate stale records.

When does a decision layer fit after records are mapped?

A decision layer fits when the plant needs a traceable recommendation and an approval step above its existing ERP and MES. Humble is one option for that role. ERP and MES retain their system-of-record roles, while the plant's integration tools and semantic model continue to map the records.

Apply the same test to the next decision

After the first scheduling decision, reuse its field owners, freshness checks, approval rights, and audit format where they still apply. Review each new line or use case for additional constraints and source conflicts before extending the rule.