An energy savings claim is only as credible as the baseline it is measured against, and this is exactly where most FMCG plants run into trouble — a baseline built from a single convenient month, without adjusting for production volume, will make almost any efficiency project look successful simply because output happened to dip, and it will make a genuinely good project look like a failure the moment production ramps back up. A properly designed baseline uses statistical methods like CUSUM analysis and production-normalized targets to separate real energy performance change from the noise of normal operating variation, which is the only way a savings number will hold up when a customer, auditor, or finance team asks how it was calculated. Plants building or defending an energy baseline can start with a conversation with iFactory's support team about connecting production and energy data into a normalized baseline model.
A Savings Claim Is Only as Good as the Baseline Behind It
Production-normalized targets and CUSUM drift detection separate a real efficiency gain from a lucky month. iFactory builds the baseline so the savings number actually survives scrutiny.
Why Raw Consumption Numbers Mislead
Comparing this month's kWh figure against last month's tells a plant almost nothing useful on its own, because production volume, product mix, and ambient temperature all move energy consumption independently of any actual efficiency change. A plant that ran fewer shifts this month will show lower energy consumption regardless of whether any efficiency project happened, and a plant claiming credit for that reduction without normalizing for the volume change is making a claim that will not survive the first serious question about how the number was derived.
Building a Baseline That Actually Holds Up
A credible baseline goes through a specific sequence, and skipping a step early in the process weakens everything built on top of it.
Establish the Relevant Variables
Production volume, product mix, and any other factor known to drive energy consumption are identified and confirmed statistically relevant before being included in the baseline model.
Select a Representative Baseline Period
A period long enough to capture normal operating variation, typically a full year to cover seasonal effects, is chosen rather than a single convenient month that happens to flatter the comparison.
Build the Regression Model
A statistical model relating energy consumption to the relevant variables establishes what energy use should look like under any given set of operating conditions, not just the baseline conditions themselves.
Apply CUSUM to Detect Drift
Tracking the cumulative sum of deviations between actual and predicted energy use reveals a sustained shift in performance well before it would be visible in monthly totals alone.
Build a Baseline That Survives an Audit
Book a 30-minute walkthrough of how iFactory constructs production-normalized energy baselines with CUSUM drift detection built in.
Baseline Methods Compared
Different baseline approaches trade off simplicity against statistical rigor, and the right choice depends on how much scrutiny the resulting savings claim needs to withstand.
| Method | Accounts For Production Volume | Best Fit |
|---|---|---|
| Single Period Comparison | No | Rough internal tracking only, not defensible externally |
| Energy Intensity Ratio | Partially, via a simple kWh-per-unit figure | Simple internal reporting with modest scrutiny |
| Regression-Based Baseline | Yes, with statistical confidence | ISO 50001 reporting and customer-facing claims |
| Regression Baseline with CUSUM | Yes, plus ongoing drift detection | Continuous performance tracking and early drift alerts |
Turning a Baseline Into Ongoing Performance Tracking
A baseline built once and filed away loses most of its value. The plants that get the most out of this work treat it as a living model that gets checked against new data continuously rather than revisited only at the next formal review.
A Composite Scenario: The Savings Claim That Didn't Survive the Next Quarter
An FMCG plant reported a meaningful energy reduction following a lighting and compressor upgrade project, comparing the three months after the project against the three months before it. The finance team celebrated the result until the following quarter, when energy consumption rose back toward pre-project levels despite the upgraded equipment still running exactly as installed.
A retrospective review found that the original comparison period happened to coincide with a planned production slowdown for scheduled maintenance, meaning much of the apparent savings reflected lower output rather than the efficiency project itself. Rebuilding the baseline using a full year of data with production volume as a normalizing variable showed the upgrade's genuine, smaller but real, savings contribution separately from the volume effect, and the plant adopted a normalized baseline for all future project evaluations specifically to avoid repeating this mistake.
Mistakes That Undermine Baseline Credibility
Choosing a Comparison Period That Happens to Flatter the Result
A short, convenient comparison window can coincidentally include a production dip or seasonal effect that inflates an apparent savings figure, exactly as happened in the scenario above.
Ignoring Product Mix Changes
Different products often carry very different energy intensity per unit produced, and a baseline that only normalizes for total volume without accounting for mix shift can still misattribute a mix-driven change to an efficiency project.
Rebuilding the Baseline Every Time a Result Looks Unfavorable
A baseline methodology that changes whenever the current comparison looks bad undermines the credibility of every claim made using it, since a defensible baseline has to be set before the result is known, not adjusted after.
Skipping CUSUM or Trend Analysis in Favor of Point Comparisons
A single before-and-after comparison misses the kind of gradual drift that CUSUM analysis is specifically designed to reveal, leaving a plant blind to a slow performance decline between formal review periods.
Is Your Baseline Ready to Withstand Scrutiny
Production volume is included as a normalizing variable
Any comparison of energy consumption between periods needs to account for how much was actually produced, or the resulting figure conflates efficiency with output change.
The baseline period spans enough time to capture seasonal variation
A baseline built from a short or unusual period risks the same trap that inflated the savings claim in the scenario above, where a convenient window masked the true underlying performance.
CUSUM or equivalent drift detection runs continuously, not just at review time
Continuous drift tracking catches a gradual performance change between formal reviews, rather than waiting for the next scheduled comparison to reveal it after the fact.
Frequently Asked Questions
What is CUSUM analysis and why is it used for energy baselines?
CUSUM, or cumulative sum, analysis tracks the running total of the difference between actual and predicted energy consumption over time, and because it accumulates small deviations, it reveals a sustained shift in performance well before that shift would be visible by simply comparing individual monthly totals against each other. This makes it particularly useful for catching a slow efficiency decline or confirming a genuine, sustained improvement rather than a temporary fluctuation.
How long should a baseline period be to produce a credible result?
Most credible baselines span at least a full year of operating data, since this captures seasonal variation in ambient temperature, production scheduling patterns, and any other cyclical factor that affects energy consumption independently of genuine efficiency changes. A shorter period risks the exact problem seen in the scenario above, where a comparison window happened to coincide with an unrelated production anomaly that skewed the result.
What variables typically belong in a production-normalized energy baseline?
Production volume is the most common and often most statistically significant variable, but product mix, ambient temperature for climate-sensitive processes, and sometimes shift pattern or equipment configuration can all be relevant depending on the specific plant and process. The right set of variables should be determined through statistical testing for significance rather than assumed, since including an irrelevant variable can weaken the model as much as omitting a relevant one.
How does a normalized baseline support ISO 50001 certification?
ISO 50001 requires documented energy performance indicators and a credible baseline against which improvement is measured, and a normalized, statistically sound baseline gives an auditor confidence that reported improvements reflect genuine performance change rather than production volume fluctuation or a conveniently chosen comparison period. Plants that build this kind of baseline from the outset generally find their certification audit proceeds more smoothly than those relying on simpler point-to-point comparisons. Book a demo to see how iFactory structures baseline data to support ISO 50001 documentation requirements.
What should a plant do if its baseline reveals no savings from a completed efficiency project?
A properly normalized baseline showing no measurable savings is valuable information in itself, since it means the project's expected benefit either did not materialize as designed or was masked by another factor not yet accounted for in the model, and either conclusion is more useful than an inflated figure that will eventually be contradicted by later data as happened in the scenario above. Investigating why the expected savings did not appear, rather than adjusting the baseline until it shows a more favorable number, is what keeps the baseline methodology credible over time. Plants wanting help investigating this kind of gap can reach iFactory support.
Build an Energy Baseline That Actually Holds Up Under Scrutiny
iFactory builds production-normalized baselines with CUSUM drift detection, so savings claims survive the next audit and the next production ramp-up. Book a walkthrough to see it running on live plant data.
