ERP Programs: Business Value and Continuity from Day One?

In almost every ERP program I’ve seen, when go-live challenges emerge, the same “lessons learned” resurface:

• Master data
• Change management
• Ownership

What makes this interesting is not that these topics appear. It’s that they appear every single time. They are not new. They are not unexpected. They were highlighted in previous programs, captured in retrospectives, and discussed in steering groups. And yet — they return.

If they are truly “lessons learned,” why do we keep relearning them?

Most programs have strong governance, structured change streams, and detailed data plans. There is communication, training, cleansing, templates, and tracking. A lot of activity.

But one question often remains unanswered:

What actually changes in daily operations — and who owns that change?

In a typical ERP setup, project roles focus on delivery, product teams focus on the system, and business roles focus on running today’s operations. The business key user sits in the middle — intended as the bridge — but is often consumed by meetings, reporting, and tool discussions, no time and room in approach to estimate potential business use impact

Future operating models rarely get the depth they require. Operational continuity is assumed — not engineered. The real surprises after go-live are rarely technical bugs. They are operational realities that were never fully thought through.

If master data and change management keep appearing as “lessons learned,” perhaps they are not the root causes. Perhaps they are symptoms of something deeper:

No one truly owning business value and continuity from day one due not even important factor in ERP programs

If we keep running ERP as a project instead of redesigning how the business operates, we shouldn’t expect a different outcome.

Same lessons.
Same structures.
Same results.

So here’s the uncomfortable question:

Are we implementing systems — or are we actually leading the business towards future and targets?

You may notice I left out the word transformation. Intentionally.

Maybe the issue is transformation without business change understanding. Maybe it’s structure.

We should design programs around bridging — clearly defining what we are changing, why it matters, and what value it must create. Roles must be simplified, ownership clarified, and outcomes made explicit.

An end-to-end, business-focused business solution architect is essential to align operating model, value, and system design. And perhaps ERP programs should only start once we truly understand the change needed in operations — and what must be built into the operational flow before UAT and go-live.

Otherwise, we will continue to deliver systems.

Not results.