How to set up products, routings, and targets

When to use this

You want your OEE numbers to be graded against what a part actually is, its real per-machine cycle-time target and its real material cost, instead of a generic plant-wide guess. That means telling the system what you make (products), how you make it (routing), and what it’s made of (BOM).

What each piece buys you

Product, the item you make (SKU, revision, unit of measure). Carries a scrap-rate target and, optionally, a standard cycle time and standard cost.
Routing, the ordered operations that make the product, each pinned to a machine (or work center) with a cycle-time and setup-time target. This is where a machine’s speed target comes from when a job for this product is running on it.
BOM (bill of materials), the components a unit is made of, each with a quantity and unit cost. The sum is the product’s material cost per unit, what a scrapped unit actually costs you.

Steps

Click Products on the Settings page (/settings), or go straight to /products.
Pick a product from the list on the left. Its detail panel shows the routing and BOM.
Read the routing as a left-to-right flow strip: each card is an operation → its machine → its cycle/setup targets. To quickly adjust a target without leaving this view, click a cycle or setup value and type the new number, it saves on Enter or when you click away. For anything structural, adding or removing a step, rewiring the sequence, changing which machine a step runs on, or editing the bill of materials, click Open process editor (or Edit in process editor next to Routing or Bill of materials) for the full drag-and-drop canvas.
Set the product’s scrap target (%), std cycle, and target rate inline the same way, in the header card. Std cycle and target rate each have their own unit dropdown next to them, whichever matches how your floor talks about it, seconds/unit, minutes/unit, or units/hour for std cycle. Units/hour, units/minute, or seconds/unit for target rate. Each is stored one way behind the scenes, so switching units just changes how the same number is typed and shown, not what’s saved. The unit you pick is remembered for that field on that product, so it comes back the same way next time you open it, independently of the other field’s unit. When creating a new product, target rate derives from std cycle automatically as you type, shown in whichever unit you’ve picked for it, until you enter a value into it directly, after which it stops following std cycle and keeps whatever you set.
Read the bill of materials list, each component shows quantity, unit cost, and line total, with the summed material cost / unit in the section header.

What it changes downstream

OEE Performance is graded per job interval against the routing cycle target for the machine that’s running, most-specific first: this machine’s routing step → its work center’s step → the product standard → the node’s configured rate. A window that spans a changeover grades each sub-interval by its own product’s target, so a changeover never smears one product’s speed onto another. The node/machine view shows exactly which target applied and why (for example, “graded against WIDGET-A routing · Stamp: 42s/unit”).
Scrap $ resolves the same product-first way: BOM component costs → product standard cost → the node’s generic per-unit cost. Every dollar surface (job costing, the Opportunities page, the executive digest, ML anomaly dollars) reads through the one resolver, so they all agree and each cites which source supplied the figure.
Changeover analytics compare the actual median changeover against the routing setup-time standard for that machine (actual vs. standard), on top of any SMED target you set.
Quality shows measured scrap next to the active product’s scrap-rate target.

Notes

Nothing is faked. If a product has no cycle target, no BOM, and no node rate, Performance and material cost stay blank (an em-dash) instead of showing a made-up number, bring what you have and the system grades what it can. More configuration buys more fidelity.
“Primary routing” for a product is its preferred step (the lowest-sequence one) when a product could run more than one way, no multi-path reconciliation is required for the base case.