Continuous improvement after go-live is the repeatable process of observing how an ERP-enabled business actually operates, identifying friction, deciding which changes deliver value, implementing them safely and measuring the result. It starts after immediate stabilization but continues through normal operations. SAP Activate's Run phase includes monitoring adoption, process performance and ongoing optimization; a mature organization assigns process owners and uses change controls rather than treating every complaint as an urgent code fix.
Stabilization and improvement are not the same
Immediately after cutover, teams prioritize transactions that cannot complete, access failures, serious data issues and operational continuity. Once the environment is stable, the work shifts toward recurring waste, poor user experience, slow handoffs and missed process benefits. A business might be able to post every invoice yet still spend many hours correcting avoidable mismatches. Improvement asks whether the process is effective, not merely whether the system is online.
Observe the process with evidence
Useful signals may include rejected invoices, manual journal corrections, inventory recounts, overdue deliveries, recurring tickets, slow approvals and user workarounds. Record a baseline and enough context to distinguish a localized training problem from a systemic design problem. Do not equate high ticket volume automatically with poor solution quality: a planned rollout or new user group may temporarily change ticket patterns. Validate observations with people performing the work.
Find the cause before funding a change
A repeated error may originate in poor master data, unclear ownership, incomplete training, integration timing, excessive approvals or genuinely unsuitable configuration. The support team can coordinate evidence, but the accountable process owner should explain business impact and approve the desired outcome. Improve the process and the solution together. Simply automating a faulty manual workaround may lock in the underlying weakness.
Example: blocked supplier invoices
After go-live, 18 out of every 100 sampled supplier invoices require a manual exception review. The business investigates whether the blocks relate to order data, receipts, tolerance policies, document timing or missing supplier information. The team defines a baseline, tests a focused improvement and measures the comparable rate after release. The numbers are illustrative, not an SAP benchmark. The point is to connect an observable problem with a measurable intervention rather than promise an arbitrary percentage reduction.
Prioritize with value, risk and capacity
Not all opportunities deserve immediate implementation. A small change that removes repeated operator effort may outrank a visually impressive dashboard. Assess operational risk, regulatory exposure, user reach, dependencies, engineering effort, testing scope and available release capacity. Separate defects that break agreed behavior from enhancements that change desired behavior. Keep the decision traceable so business owners can see why one request moved before another.
Test and release without harming stable work
Once a proposal is approved, the change needs explicit acceptance criteria, representative test cases, integration checks, appropriate segregation of duties and a governed release window. For changes that touch finance postings or warehouse execution, assess downstream controls and reconciliation. Communicate the operational change to affected teams and monitor its early effects. A deployment is not evidence of achieved improvement until users can complete the intended business process more effectively.
Measure adoption, not just completion
Track the original measure after release: fewer avoidable exceptions, less rework, faster processing at similar volume or higher user compliance. Investigate whether the result persists and whether a new problem appeared elsewhere. A support ticket marked 'closed' does not prove the underlying process benefited. When a change fails to deliver, adjust or reverse it under change governance rather than quietly declare success.
Close the loop with accountable ownership
Process owners define business outcomes, users supply operating context, consultants assess process and solution implications, IT/support maintains reliable operations and governance roles approve material risk. SAP's Activate guidance identifies the Run phase as ongoing performance review, adoption monitoring and refinement. The practical consultant habit is to ask: What is the baseline, what caused the problem, who owns the decision, how will we test it and when will we measure the result?
Related Knowledge
How Enhancement Requests Are Prioritized · Root Cause Analysis for Recurring Issues · How Support Releases Are Planned · How Emergency Fixes Are Governed. Explore Consulting & ERP Projects.