Ask any SAP consultant what success looks like, and they’ll often point to go-live as the main milestone. But once the dust settles, the task of turning that new setup into measurable value begins. This is what many refer to as the value realization phase.
It might be called “the Run phase”, or “what happens after go-live.” But whether or not a project labels it, this is a crucial stage determining whether the investment in SAP ends up meeting business expectations. This article from IgniteSAP considers that period and the factors which influence whether it can bring about optimal results as the project matures.
One of the reasons it gets overlooked is that project teams tend to disband soon after go-live.
But just because the project is “done” doesn’t mean the benefits are locked in. In fact, the majority of those benefits are still up for grabs. Without deliberate work after go-live, many of the promised gains don’t materialize.
This article from IgniteSAP shows how this is where SAP consultants, particularly those working closely with customers post-go-live, can play a different role as stewards of value. Both project teams and stakeholders can treat the post-deployment period as a longer, more adaptive phase of work.
Most SAP implementations focus heavily on delivery, and less attention is given to whether the intended business outcomes are being delivered after the system goes live.
This has consequences. When value is not actively tracked and pursued, SAP systems risk becoming expensive tools used to replicate old processes in new formats. There might be fewer paper forms or fewer manual steps, but the underlying ways of working can remain unchanged. The potential for improvement gets lost in the rush to “stabilize” operations.
Some organizations notice this drift and try to correct it later, usually through new projects or process audits. But the early post-go-live period is the most responsive time to introduce changes, not years later when everyone has already adapted to the system as it is.
If no one defines what success looks like before go-live, then no one knows what to look for afterward. There’s no baseline, no clear owner of the benefit, and no process for reviewing whether those benefits are apparent in live performance. That doesn’t mean the benefits aren’t there, but that no one’s watching closely enough to say either way.
Consultants who raise these points early, even if they’re not directly responsible for business KPIs, set the project up for a more productive and measurable post-go-live journey: keeping value in view long enough for it to become reality.
The value realization phase begins just before go-live and continues well into the Run phase. In the SAP Activate framework, it’s situated after the Deploy phase. But its roots stretch back much earlier.
During the Prepare and Explore phases, teams have the chance to start shaping what will eventually become the markers of success.
Business process workshops, system design decisions, and scope discussions are all moments where future value can be defined and planned. If the process owner for procurement wants to reduce spend, now is the time to clarify how that is defined, what system behavior would support it, and how it might be tracked after go-live.
These conversations need to be specific. “Improve procurement” isn’t helpful. “Track catalog compliance on indirect spend and flag exceptions weekly” is. That level of detail gives internal teams something to build and something to monitor. It also gives post-go-live teams a clearer path to measuring progress.
Once the system goes live, the window for shaping behavior is short. Hypercare typically lasts four to six weeks. Stabilization efforts are focused on keeping operations running. But even here, value realization work can help. Support teams can start logging what friction points suggest deeper process issues. These logs can evolve into a backlog for improvement sprints later in the Run phase.
As the system settles and Run operations begin, the question becomes: are the benefits we aimed for validated in our data?
By the time a project enters the Run phase, many of the original delivery teams are no longer involved. The work often becomes the responsibility of a centre of excellence (COE), internal support teams, and line-of-business owners. What makes this phase different from day-to-day system support is its focus on continuous performance improvement rather than just system availability.
This requires structure. First, there needs to be a way to monitor how processes are actually performing. That might mean using tools like SAP Signavio for process visibility, or checking reports from SAP Analytics Cloud. The key is that the reports link back to something the business cares about, such as turnaround times, error rates, or compliance rates.
Second, someone needs to be accountable for each benefit identified before go-live. That person doesn’t have to solve every problem, but they do need to track the data, lead conversations about what’s working and what’s not, and coordinate improvements with IT or support teams.
Third, there needs to be a regular review. Most successful organizations review value realization progress monthly in the early Run phase and then shift to quarterly reviews as the system stabilizes. These meetings are business reviews that look at whether the investment is starting to return results.
Finally, Run-phase governance depends on having a backlog of improvements. These can come from user feedback, process logs, audit findings, or reports. Continuous improvement requires a place where change requests go, a way to score them, and a way to work through them in planned sprints or releases.
Once the Run phase is underway, there’s no shortage of data, tickets, or feedback from users, but the signal can get lost in the noise. This is when structured tools and accelerators can help teams focus their energy.
Some SAP customers use tools like SAP Signavio to see how their processes actually flow in practice, and to highlight deviations from standard paths, delays between steps, and handoff issues between departments.
Other organizations use SAP’s own frameworks, like the Value Lifecycle Manager or the prebuilt scenarios in the Signavio Value Accelerator Library. These provide templates for common value drivers like reducing days sales outstanding, improving first-time-right rates, increasing catalog usage in procurement. The advantage isn’t in the template itself so much as in having a starting point that links system use to business priorities.
More traditional governance tools like SAP Solution Manager or SAP Cloud ALM can help maintain structure in how changes are tracked, tested, and deployed. They also help avoid the unstructured daily fixes and undocumented adjustments that accumulate in systems over time. If a change results in an improvement, there should be a way to prove it. If it causes a new problem, there should be a path to reverse or refine it.
What matters most is that tools support the process of discovering, scoping, delivering, and measuring improvements. They shouldn’t become a project of their own, but should serve the goal of converting business needs into small, trackable gains.
Value is easy to talk about and harder to pin down. That’s why metrics matter, not just in theory, but in daily practice. The most common mistake in the value realization phase is to focus on activity instead of outcomes. Launching a new report is not a result. Shortening a reporting cycle by three days is.
Before go-live, teams should identify a handful of business metrics they expect to improve as a result of the project. These metrics should be owned by the business, not just IT. For example, if one of the goals is to speed up the invoice approval cycle, then the finance operations lead should be part of defining that metric, setting a baseline, and reviewing progress post-go-live.
Good metrics are specific, time-based, and connected to a business priority. They can be operational (like order processing time), financial (like working capital), or behavioral (like catalog compliance), but all should address a business priority.
If a metric is seen in review to be improving, the team can dig into why and see if the improvement can be repeated elsewhere. If it’s flat or moving in the wrong direction, that should trigger investigation of whether the process, data, training, or system configuration needs attention.
Having a scorecard helps, but only if the numbers are linked to ownership and action. Metrics without names next to them tend to get overlooked. Value realization only happens when someone takes those numbers and starts asking questions.
The structure of the team after go-live plays a big role in whether value realization becomes an active process. It’s not enough to have a help desk or an incident management team. Those functions keep the business supported, but they don’t move it forward.
Ideally, a centre of excellence (COE) should handle support and improvement. This team sits between IT and the business, translating needs in both directions. It keeps track of process performance, manages the improvement backlog, and acts as a home for system knowledge and training materials.
Alongside the COE, it helps to have people in the business who are responsible for specific outcomes. If they’re trying to increase self-service in HR, reduce returns in logistics, or improve on-time delivery, they’re the ones watching those numbers and working with the COE to act on them.
A third layer is a steering group or Run-phase governance board. This group reviews the bigger picture each quarter. It looks at whether the project’s promises are being kept, whether value is growing, and whether new opportunities are emerging as the business learns to work differently.
This structure doesn’t need to be large or formal. But without it, the risk is that Run-phase work becomes a string of isolated fixes with no direction or learning curve.
While the focus of the Run phase is often on value creation, it should also guard against value loss. It’s easy to think that once a system is live, the risk level goes down. In some ways, it does. But new kinds of risks appear that slowly erode the usefulness of the system.
One of these risks is technical drift. Over time, small changes made to meet urgent needs can pile up, creating complexity that’s hard to manage. This includes things like unapproved enhancements, inconsistent master data handling, or undocumented workarounds. Without regular reviews and a formal change management process, these changes can turn a clean system into a messy one.
Another risk is complacency. If metrics aren’t tracked, if owners aren’t clear, if improvement cycles don’t happen, then the system still runs, but it stops evolving. That can be just as damaging as instability: especially in industries where expectations are rising and competitors are moving quickly.
Compliance and audits also play a part. New regulatory changes, security concerns, and data privacy rules all affect how SAP systems operate. If governance doesn’t adapt to these, the cost isn’t just legal: it’s operational, as processes are forced to pause, adjust, or backtrack.
Good governance in the Run phase means knowing what changed, why it changed, who changed it, and how it affected performance.
Some of the most effective work for the Run phase happens before go-live when teams still have access to delivery resources, attention from sponsors, and the chance to set expectations clearly.
The most useful thing teams can do in this period is define what they want to happen after go-live: not just in terms of system stability, but in terms of business change. That means creating a small set of KPIs, assigning owners to them, and building dashboards or reports that will be used to track them.
It also means thinking about how the system will be governed after the project closes. Will there be a backlog? A sprint calendar? A process for requesting changes? These are simple, but if they’re not defined early, they tend to fall apart.
Another smart move is to start process mining or data monitoring before go-live. That way, the team has a baseline to compare against.
Some organizations formalize their approach to post-go-live value through what’s called a Value Realization Operating Model. This is a structured way to run the Run phase, with defined roles, review cycles, and planning methods.
At the heart of the model is a small team (sometimes inside the COE, sometimes in the business) tasked with reviewing value KPIs, managing improvement work, and reporting on progress to leadership.
The VROM needs commitment. Its job is to keep value conversations alive, after the initial excitement of go-live fades.
If the Run phase is going to succeed, it helps to have a rhythm. That means having playbooks for hypercare, templates for benefit tracking, and calendars for when reviews happen and changes are delivered.
Hypercare playbooks should describe what happens in the first few weeks: who triages issues, how decisions are escalated, how users are supported. Benefit tracking templates list the KPIs, their definitions, their owners, and where the data comes from. Review calendars show when updates are expected and who needs to be in the room.
These tools give teams a way to follow through: not just on problems, but on progress.
Treat value realization as a phase of work. Don’t assume that improvements will appear just because the system is working. Check the numbers. Stay close to the business. Keep a backlog and keep reviewing it. And most importantly, keep talking about value as something the project was meant to deliver.
In many ways, value realization is the reason the project exists in the first place. If consultants, teams, and business leaders treat it that way, then SAP systems deliver business benefits. And that’s the main difference between implementation and transformation.
If you are an SAP professional looking for a new role in the SAP ecosystem our team of dedicated recruitment consultants can match you with your ideal employer and negotiate a competitive compensation package for your extremely valuable skills, so join our exclusive community at IgniteSAP.
Why Growth Rate Is the Wrong Metric for Judging an SAP Employer
How to Identify the Ceiling in Your Current SAP Career Path
