The glaze printer, fully linked to the ERP

The problem

The last aesthetic decision before the kiln is a manual selection.

The digital printer is the last aesthetic decision before an irreversible process. A wrong recipe selection turns into a full-run scrap, undetected until the kiln exit.

• The digital inkjet printer that decorates every tile is modern and has an API, but it is isolated from the ERP: the operator picks the design recipe from a list. The ERP knows which design the order needs; the printer does not.
• A collection can have dozens of designs and graphic variations, with similar names and formats that differ by a few centimeters. Under the pressure of a startup, the wrong one is one click away. The printer accepts any recipe it has; it has no way of knowing which order is active.
• A wrong pick is not visible on the glazing line. The tile only shows its real color after firing, so the error is discovered at the kiln exit, when the whole run is already fired.
• At that point there is no rework: a full run of the wrong design or shade is scrap or a downgrade, and the kiln time spent on it is lost too. On a continuous line, the next run is already waiting behind it.

How it fits the IRIS system

Connect between two modern systems — the ERP publishes the recipe to the printer.

Connect links two modern systems via API. When the ERP/MES flags a line startup with a specific format/design, it automatically publishes the matching recipe to the printer.

When the ERP or MES marks a line startup with a format and a design, the matching recipe and batch are published to the printer. The operator no longer chooses; they confirm what has already arrived. It is the shortest integration in the matrix and one of the fastest to pay back. Neither system is replaced; they simply start talking to each other.

See the full IRIS architecture →

Before and after

Recipe selection today versus recipe published from the ERP

Aspect	Today	With iLEAN Connect
How the design recipe is chosen	Picked from a list by the operator	Published from the active order
Batch on the printer	Typed or omitted	Travels with the recipe
Similar design names	A source of mistakes	Irrelevant: the code travels
When a wrong pick is found	At the kiln exit	Not made
Full-run scrap from recipe error	Several times a year	Zero of human origin
Inkjet printer software	—	Untouched, linked via its API

Monthly recipe-selection errors (with associated scrap) → zero human-origin error.

Impact estimate

Impact estimate — to be validated with your numbers.

The block below is an estimate to be validated against your plant's actual data. We put it forward so the committee has an order of magnitude; we refine it during the assessment.

• Estimated payback 3-6 months, one of the fastest in the matrix.
• It comes from the drastic reduction in the risk of scrapping a full fired run because of a wrong recipe.
• Monthly recipe-selection errors, with their associated scrap, drop to zero errors of human origin.
• And every fired run carries a trace of which recipe it was printed with and which order it came from. That trace closes a shade or design complaint in minutes.

Fast payback, 3-6 months, from the drastic reduction in full-run scrap risk. *Estimate to validate*.

And the fair question from the production manager

“And if the ERP order itself carries the wrong design?” — then the error would come from the order, not from the link, and that is why the printer shows the received recipe for the operator to confirm before printing. Matching an order's format and design code with the printer's recipe library is an anchored task, where the best models drop below 1.5% error [1], and here it is mostly a deterministic API lookup. If the code does not exist in the printer's library, nothing is loaded and the operator is warned.

^[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.