Energy by Shift and Product: A Guide to Machine-Level Energy Intensity

Machine-level energy intensity at a glance

Energy per part is the right metric until the product mix changes, and then it quietly stops being comparable. Two shifts running different products can show very different kilowatt-hours per part while operating identically well, which is enough to derail a shift-comparison meeting and to send an improvement team after a problem that does not exist. The fix is not a better single number. It is two denominators, runtime hour and good unit, used together, with the product mix normalised before any shift is compared to another. Idle energy then gets pulled out as its own line, because it behaves differently from both.

Why energy per part is not enough

Because it moves with the product, and most shift comparisons change the product.

Energy per part is the right starting metric and Guidewheel's machine-level energy monitoring guide covers how to build it: total machine kilowatt-hours divided by good parts produced. That article also already compares energy per part across shifts and operators, so this one starts where it stops.

The limitation appears the moment two periods run different work. A worked case:

Day shift. Runs product A, a thick-wall part with a 90-second cycle and a heavy clamp load. Produces 320 parts, consumes 640 kWh. Energy per part: 2.0 kWh.

Night shift. Runs product B, a thin-wall part with a 45-second cycle and a lighter load. Produces 610 parts, consumes 610 kWh. Energy per part: 1.0 kWh.

Read naively, night shift is twice as energy-efficient and day shift has a problem. In fact both shifts ran the machine identically well. The difference is entirely the product, and any improvement effort aimed at day shift on this evidence is aimed at nothing.

Now invert it. Suppose night shift had consumed 850 kWh for those 610 parts, giving 1.39 kWh per part. Still better than day shift's 2.0, so still invisible in a shift comparison, and yet something on night shift is drawing 40% more than it should for that product. Energy per part concealed a real problem because the mix difference was larger than the performance difference.

That is the failure mode. Energy per part is not wrong; it is uninterpretable across changing work, in both directions.

The fix needs a denominator the product cannot move.

The second denominator: kWh per runtime hour

kWh per runtime hour is energy consumed divided by time the machine was actually running, excluding idle and down time entirely.

It answers a different question from energy per part: not "what did this part cost" but "how hard is this machine drawing while it works". Because the denominator is time rather than output, product mix moves it far less. A machine running a light product still draws roughly its characteristic load while running; it simply produces more parts per hour.

Return to the two shifts. Day shift: 640 kWh across 8 hours of runtime is 80 kWh per runtime hour. Night shift at 610 kWh across 7.6 hours of runtime is 80.3. On this denominator the two shifts are identical, which is the correct conclusion and the one energy per part obscured.

Apply it to the concealed-problem version. Night shift at 850 kWh across 7.6 runtime hours is 112 kWh per runtime hour against day shift's 80, a 40% difference on a mix-independent measure. The problem that energy per part hid is now the most obvious number on the page.

What it isolates: the machine's draw characteristics. Rising kWh per runtime hour on an unchanged asset points at something physical: a heater cycling more than it should, a hydraulic system working harder, a drive drawing more for the same work, a compressor loading against a leak.

What it hides: everything about output. A machine can post excellent runtime-hour intensity while producing very little, because idle and down time are excluded from the denominator by construction. That is why the two metrics are used together rather than one replacing the other.

A caution. If run rate varies substantially within the period being compared, the metric blurs. On assets that routinely run at different speeds, segment by speed band before comparing.

Neither denominator fixes the case where the mix differs and you still need a like-for-like comparison.

Normalising for product mix

Weight each product by its own expected energy, then compare actual against expected rather than comparing shifts directly.

The method, in four steps.

1. Establish an expected kWh per part for each product, from stable runs on that machine. Use the same definition of a stable run you use for cycle time: quality met, no stoppages, representative conditions.
2. For the period being compared, compute expected total energy as the sum across products of expected kWh per part multiplied by parts produced.
3. Compute the energy index as actual total energy divided by expected total energy.
4. Compare the index, not the raw kWh per part.

Worked example. Expected values: product A at 1.9 kWh, product B at 0.95 kWh.

• Day shift: 320 of A. Expected 608 kWh. Actual 640. Index 1.05.
• Night shift: 610 of B. Expected 579.5 kWh. Actual 610. Index 1.05.

Identical, correctly. Now the concealed-problem version: night shift actual 850 against expected 579.5 gives an index of 1.47, against day shift's 1.05. The comparison is now valid despite the products being different.

Assumptions to state openly. The expected values are only as good as the stable runs behind them, they must be re-derived when tooling or material specification changes, and the method assumes energy scales with part count within a product, which breaks down if batch size varies enormously because of setup and warm-up load.

Sensitivity. If your expected values are 10% off, the index is 10% off for every period equally, so the comparison between periods survives even when the absolute figure does not. That is the property that makes this worth doing: you need the expected values to be consistent, not perfect.

One category of consumption resists all of this, and it deserves its own line.

Isolating idle energy

Report idle energy separately from both denominators, always, because it behaves differently from either and it is usually the fastest thing to act on.

Idle energy is what the machine consumes while powered and available but not producing. It does not scale with output, it does not scale with runtime, and it sits inside every aggregate figure quietly inflating it. A machine with high idle draw looks moderately inefficient on energy per part and slightly odd on runtime-hour intensity, and the actual cause is invisible in both.

Measured on its own, it becomes obvious and actionable. Guidewheel's Nice House of Plastics case study reports the plant reducing weekly idle time by 67%, with idle draw falling from 1,500 kWh per week to consistently under 500, a saving Guidewheel puts at around 52,000 kWh per year or approximately $4,644 annually.

Two things about that figure are worth reading carefully. The headline metric is idle time, while the kilowatt-hour figures describe idle energy; they are related but not the same measurement, and conflating them is a common error. And the dollar figure depends on that plant's tariff, so treat it as an illustration of scale rather than a rate to apply to your own plant. Recompute against your own cost per kilowatt-hour before putting a number in a business case.

How to report it. Idle kWh per week per machine, trended, with the machines ranked. That single ranked list is usually the most immediately useful energy artefact a plant can produce, because the top entries are almost always fixable by a shutdown procedure rather than by capital.

Where idle energy comes from, in rough order of frequency: thermal assets held at temperature through breaks and overnight, hydraulic systems left energised, drives and conveyors running with nothing on them, compressors cycling against demand that no longer exists, and control cabinets and ancillaries that nobody has ever switched off.

The off-hours version of this analysis is a discipline of its own, covered in compressed air and phantom loads.

Turning it into an operating review

A metric that is not on a standing agenda is a report, and reports do not change consumption.

Weekly, at shift-review level. Two numbers per machine: the energy index for the week, and idle kWh. Nothing else. The question is whether either moved, and if so what changed. Five minutes.

Monthly, at plant level. The ranked idle list, the index by machine trended over three months, and any expected-value revisions from tooling or material changes. The question here is which machine to investigate, and who is doing it by when.

Quarterly, at operations level. Whether the expected values still hold, whether the index baseline has drifted, and whether the savings claimed earlier are still present. This last one is the check almost nobody runs, and it is where most energy programmes quietly unwind.

Assign one owner. Energy sits in a gap between operations, maintenance and facilities, and unowned metrics decay faster than owned ones. It does not much matter which function holds it as long as one named person does.

Three practical cautions.

Do not build the review around the utility bill. It arrives late, it aggregates everything, and it cannot tell you which machine or which shift. It is a finance artefact, not an operational one.

Do not chase a machine because its absolute consumption is high. Large machines consume a lot legitimately. The index and the idle figure are the signals, not the raw total.

Do not claim a saving without re-measuring the same window. A change that coincided with a lighter production month will look like a saving and is not.

For costing what you find, see energy cost per machine, and for the broader programme view, cut factory energy costs.

Frequently asked questions

About the author