The project doesn’t end at go-live:
adoption and value are the real test of an SAP transformation

In many organizations, go-live is treated as the finish line. The system goes live, on schedule (or close to it), congratulations circulate through the corporate inbox, and the project team disperses. It’s a real milestone and it deserves recognition. But go-live doesn’t answer the only question that matters to the board: is the company actually using the solution and capturing the value that justified the investment?

In practice, go-live isn’t the end. It’s the starting line. And it’s precisely in the months that follow — once the project spotlight fades — that it’s decided whether an SAP transformation will deliver results or merely swap out one system for another.

The paradox of the solution nobody uses

There’s a quiet pattern, and a more common one than people admit: the company implements, but the operation keeps working the way it always has. Parallel spreadsheets survive on the margins of the ERP. Legacy processes hold on because “that’s how we’ve always done it.” Modules that were contracted, justified, and configured never make it off the page. The system is live — but the business hasn’t changed.

Market figures help size up the problem. According to Gartner, by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet the goals of their original business case — and roughly a quarter of them will fail severely. The most important part of that statistic tends to go unnoticed: technology is rarely the culprit. The software works. What fails is adoption.

The waste embedded in this is concrete. Also according to Gartner, around 30% of software-as-a-service spending is considered “toxic” — consumed by licenses and features nobody uses — and organizations lose, on average, about a quarter of their SaaS budget to entitlements that sit idle. This is the shelfware phenomenon: contracted capability that turns into software left on the shelf.

Within the SAP ecosystem itself, the signal is just as clear. SAP’s own value-measurement tools frequently show customers using only a fraction of the capabilities available in the solution — for example, thirteen out of thirty capabilities in one process area, twenty out of thirty-five in another. The potential is contracted and available. It’s the activation, and the value that comes with it, that doesn’t happen on its own.

Adoption isn’t an event. It’s culture.

When the project ends, organizational gravity pulls the operation back toward the comfort of the familiar. Overcoming that force isn’t a matter of more one-off training at go-live — it’s a matter of culture.

Real adoption depends on four things no software delivers on its own: visible executive sponsorship (the transformation can’t be perceived as “an IT project”); clear accountability of business leaders for the results; change management that stays active long after cutover; and — perhaps the most neglected factor — continuous measurement of usage.

Here the oldest principle in management applies: what isn’t measured isn’t managed. A good share of companies can’t answer, twelve months after go-live, how many users actually operate in the system, which features are active, or whether the indicators promised in the business case have improved. Without that visibility, adoption becomes cheerleading, not management.

Putting adoption into the culture means making it the default way of working — not the alternative that coexists with the old shortcuts.

Measuring usage is the start. Measuring value is the goal.

There are two layers of measurement, and confusing them is an expensive mistake. The first is usage: logins, transactions, active features, adherence to the designed process. It’s necessary, but insufficient. The second, harder and more important, is value: did the financial close cycle get shorter? Did capital tied up in inventory go down? Did the order cycle shrink? Did data accuracy improve enough to change decisions?

Measuring value requires a baseline defined before the project and reviewed continuously afterward. It’s no accident that SAP itself has structured much of its recent process-management and adoption-monitoring portfolio around one central idea: that value realization is a continuous discipline, and that transformation doesn’t end at go-live. When that follow-through is missing, the projected value stays exactly where it was born — on the business-case slide.

The partner who doesn’t walk away at go-live

This is the point where the choice of consulting partner stops being an implementation detail and becomes a direct determinant of outcome.

Most market models treat go-live as the end of the contract. The model that actually captures value treats go-live as the start of a new phase. A well-run SAP journey has four connected moments, and none of them ends at cutover:

• Before the project, mapping the value levers and building a business case that quantifies the expected financial impact, connecting each initiative to a result.
• During the project, running execution with governance, KPI monitoring, risk management, and predictable, transparent reporting.
• During adoption, accelerating usage, measuring the real impact on the business, and identifying new value opportunities that only surface once the system is genuinely running.
• In operation and evolution, sustaining stability with specialized, SLA-based support and continuously evolving capabilities as the business changes.

This is precisely the principle that guides Exed: acting as a value partner, not just an implementer — from the business case to continuous evolution. As SAP specialists focused on depth (not generalists), with a customer-success model that follows the journey beyond go-live — combining adoption, specialized AMS, and continuous evolution — the goal stops being “get the system live” and becomes sustaining the predictability of captured value over time. It’s no coincidence that this kind of ongoing relationship shows up in satisfaction: an average NPS above 8.7 across every phase of the journey is what you’d expect from a partnership that begins at go-live, and doesn’t end there.

The question that changes everything

Go-live deserves to be celebrated — but as a milestone, not a destination. The difference between a transformation that delivers and one that disappoints rarely lies in the software chosen; it lies in who runs the journey after the project lights go out, in how the company embeds usage into its culture, and in whether someone is there, side by side, measuring and protecting value over time.

For the executive sponsoring the investment, the right question was never “when do we go live?” It’s “how will we ensure, measure, and sustain value after we go live?” Whoever answers that question before go-live captures the return. Whoever only asks it afterward usually discovers, too late, that the value stayed on the slide.