The Process That Went Live Unchanged
Six months after go-live, the scheduler still opens the scheduling spreadsheet first.
The ETRM is running. Users were trained. The project closed on time. And the spreadsheet is still the first file opened every morning, because it is still the version the desk trusts.
Nobody calls that a failed implementation. On paper, it isn’t one. It is something harder to see and more expensive to fix: a platform that became the system of record without ever becoming the system of work.
The signs are familiar. Confirmations still move through email, because the configured workflow takes longer than the counterparty will wait. Month-end reconciliation is assembled in Excel and posted back into the platform. Someone maintains a separate position file – not out of habit, but because it is the one they would defend in front of the CFO.
Each of those is a small, rational decision. Together, they are where the investment case goes awry.

It is replication, not resistance
The instinct is to call this adoption. Sometimes that is fair – training, change management, and clear accountability all matter, and they are worth funding properly.
But training cannot rescue a workflow that is slower, less reliable, or less useful than the workaround it was meant to replace. People do not route around systems that work.
The more likely explanation is less comfortable: the organization configured its current process before deciding what its future process should be.
Under delivery pressure, that is the rational choice. Current-state steps are known, testable, and easy to defend in a status meeting. “Configure it like the old system” is the lowest-risk sentence anyone can say in a design workshop.
The problem is that many of those steps were never business requirements. They are residue of a platform that could not do something, an interface that failed twice a week, a role that went unfilled for a year, a workaround that outlived the reason for it. Configured into the new ETRM, that residue stops being a workaround. It becomes the design.body it.
A process map shows what. It does not show why.
Documenting the workflow is the easy half. Understanding why each step exists is the part that gets skipped.
In energy and commodities, that reasoning usually lives in judgment rather than documentation – across trade capture, nominations, confirmations, settlement exceptions, inventory reconciliation, credit, and month-end close.
When a long-tenured expert retires or resigns, the immediate loss is capacity. The lasting loss is the ability to tell a genuine control from an inherited one.
On a process map, the two look identical.
So before configuration hardens, sponsors should require one question to be asked out loud for every significant step:
Every change brings its own challenges, but with the right approach, it can also bring immense growth and opportunity.
Most steps survive the question. The ones that do not are the steps you would otherwise have paid to rebuild, then paid again to work around.
The business case leaks quietly
No one signs off on an ETRM investment because they want new software. They sign off for what it is supposed to produce: control, reporting that can be acted on without being reconstructed first, and the capacity to add volume without adding headcount at the same rate.
Those returns do not arrive while the manual touches stay.
And the loss rarely becomes visible enough to escalate. There is no outage and no incident. Reporting just keeps requiring manual assembly. Exceptions keep surfacing late. Confidence in the numbers erodes a quarter at a time. Nothing gets reported, because there is nothing to report – the organization simply pays for a modern platform while carrying the cost and risk of the old operating model.
Optimus has seen this pattern in complex environments, where inconsistent trade capture, informal handoffs, limited process visibility, and lagging inventory data turned every month-end into a reconstruction exercise. What changed the outcome was not more configuration. It was process review, named ownership, control design, and scenario-based testing run alongside the ETRM work rather than treated as cleanup after it.
What sponsors should require
Three disciplines make a material difference.
Map the work, not the workflow.
Trace real transactions, including the ones that go wrong – from trade entry through scheduling, settlement, accounting, and reporting. Follow them into the spreadsheets, the email threads, and the offline steps. That is where the process actually lives.
Decide the future state before configuration hardens.
For each major workflow, separate the essential commercial and control requirements from the behaviors invented to survive the old platform. This is a decision, and it has an expiration date.
Name owners, and give them time.
Process redesign requires meaningful involvement from the people who run the work day to day, but it cannot rely entirely on their availability around normal operating demands. If no one has the capacity to lead decisions, coordinate stakeholders, and carry the work through design and testing, that is a delivery risk that should be addressed through realistic resourcing, priorities, and governance.
On one Optimus ETRM upgrade, cross-functional teams worked through current- and future-state workflows together, identified handoff and control gaps that no individual function could see alone, and built test scenarios around real operating conditions. The upgrade went better for it. More importantly, the organization emerged with defensible processes, clearly named owners, and a shared understanding of how the work should run.
The test that matters
The question after go-live is not whether the project plan closed. It is whether the business can execute inside the new operating model.
At 30, 60, and 90 days, ask four things:
- Which spreadsheets are still in daily use?
- What business decision does each one support?
- Is it a governed exception, or evidence that the process still lives outside the ETRM?
- Can the organization absorb more volume without adding manual effort at the same rate?
If those answers are vague, the platform is probably not the problem. The technology changed. The process did not.
Talk to Optimus
Optimus supports energy and commodities organizations with ETRM consulting, business-process review, implementation and transformation support, and the specialist recruiting and contract staffing needed to execute change.
If you are planning an ETRM upgrade, migration, or reimplementation – or your team is already live and still running on shadow processes – talk with an Optimus expert about where process, technology, and resourcing are misaligned.
