Discrete and process manufacturers with one to a handful of plants. Assumes an ERP with a long history, some shop floor data on paper, and at least one system inherited from a migration.
True margin by part and customer
In one line: Shows what each part actually costs to make for each customer, including the scrap and rework nobody books properly.
Who uses it and when: whoever sets pricing, at the regular margin review, on a ranked list of parts and customers by real margin instead of one overall number. It changes one decision: which part or customer gets repriced next.
What it does not do: it will not reprice the part. It shows where the margin is actually going; the pricing call is still a person’s.
Usually needs work.
It depends on production data that is already recorded at the operation level, one work order and routing step at a time. The same part carries three item numbers because of an old ERP migration nobody cleaned up, so per-part totals split three ways. Scrap and rework hours go to a catch-all code, so the cost of quality is invisible by design. Nothing new has to be built. The item numbers get merged to one, and scrap and rework get their own codes.
The pain: “We know our overall margin. We have no idea which parts and which customers are making it and which are eating it.”
What it runs on
- One row per: one operation completed on one production order. One work order, one routing step, one work center, one shift. Setup, run, scrap and rework each recorded, not merged.
- Described by: part or item, customer, work order, work center or machine, operator and shift, routing operation, material lot, date.
- Must agree across systems: part number, customer, work center, and unit of measure. Unit of measure is the one people skip and it is the one that produces indefensible numbers, because pounds, each, and cases are all “quantity.”
- History: you need history on standard costs and routings, with effective dates. Otherwise last year’s jobs get revalued at this year’s standards and every historical margin is quietly wrong.
Why it usually fails: the same part carries three item numbers because of an ERP migration that was never cleaned up, so per-part anything is split three ways. Scrap and rework hours go to a catch-all code, so the cost of quality, which is usually where the margin went, is invisible by design.
Downtime and maintenance prediction
In one line: Predicts which machine is about to stop the line, so maintenance happens on your schedule rather than on the machine’s.
Who uses it and when: the maintenance lead, before the shift starts, on a short list of which machine is likely to go down next instead of a reactive callout. It changes one decision: which machine gets serviced on this week’s schedule.
What it does not do: it will not perform the maintenance. It flags which machine is due for attention before it stops the line.
Usually needs work.
It depends on downtime events, which do get logged, just imprecisely: on a clipboard, typed in at the end of shift with a guessed duration, and a reason code that is usually “other.” The bigger gap is that maintenance calls the machine “Press 2” and production calls it “PRS-002,” so the two histories cannot be joined at all. Nothing new has to be built. One name wins per machine, and duration gets timestamped instead of guessed.
The pain: “The same three machines take the line down and we are always reacting to it.”
What it runs on
- One row per: one downtime event. One machine, one start time, one end time, one reason. Paired with one row per machine per hour of run status, so uptime can be measured against a real denominator.
- Described by: machine or asset, line or cell, plant, reason code, shift and operator, date and time, product being run at the time, linked maintenance work order.
- Must agree across systems: the asset above all. The maintenance system, the production system, and the fixed asset register have to be pointing at the same physical machine. Then plant, product, and shift calendar.
- History: you need asset history. A rebuilt or retrofitted machine behaves like a different machine, and comparing its performance before and after only works if the change is dated.
Why it usually fails: downtime is logged on a clipboard and typed in at end of shift with a guessed duration, so the durations are rounded fiction. Reason codes are dominated by “other.” And the maintenance system calls the machine “Press 2” while production calls it “PRS-002,” so the maintenance history and the downtime history cannot be joined.
Demand forecast and inventory right-sizing
In one line: Sets stocking levels from real demand instead of last year plus a feeling, and shows which inventory is dead.
Who uses it and when: the buyer or planner, at the regular reorder point, on stocking levels set from what customers actually asked for instead of last year plus a guess. It changes one decision: how much of an item to order next.
What it does not do: it will not catch demand that was never recorded in the first place. It is only as good as what got written down when the customer asked.
Usually needs building.
It depends on knowing what customers actually asked for, and what gets recorded instead is what shipped. When an item is out of stock, demand for it looks like zero, so the forecast learns to order even less and the stockout reinforces itself. The order that could not be filled is not written down anywhere, only the ones that were. Recording requested demand, not just shipped demand, is the project. The feature is what happens after it.
The pain: “We are out of the parts customers want and buried in the ones they do not.”
What it runs on
- One row per: one order line shipped, on one date. Paired with one row per item per location per day for on-hand quantity. As with bank balances, on-hand adds up across warehouses but never across days.
- Described by: item, customer, ship-to location, warehouse, sales channel, salesperson, promotion, order date, ship date, requested date.
- Must agree across systems: item, customer, ship-to location, calendar, and unit of measure again.
- History: you need history on item classification and on customer identity. When two customers merge through an acquisition, their history has to merge with them or the forecast breaks at exactly the wrong moment.
Why it usually fails: demand is measured from shipments. When you were out of stock, demand looks like zero, so the forecast learns to order even less and the stockout becomes self-reinforcing. Recording what was asked for, not just what shipped, is the fix, and almost nobody does it.