SAP that lands. Not just SAP that goes live.

End-user training is one component of change management — and not the most consequential one. Change management is the discipline of redesigning the operating model around what the new system can now do, building stakeholder commitment across leadership and the front line, redesigning roles and responsibilities, communicating the why and when, then enabling people to use the new system and measuring whether the business case actually lands. Training is the enablement chapter at the end of that sequence. Programmes that treat change management as training schedule end-user sessions, declare 'people are trained', then watch productivity flatten because the work around the system was never redesigned. DEBCOR's practice runs all four disciplines — process design, organisational change, end-user enablement, value realisation — with the same senior-led discipline as the technical track.

At the business case, not at user acceptance testing. The most expensive change-management problems are baked in during scoping — when the programme buys a system whose to-be processes the business has never actually committed to, when stakeholder alignment looks complete in the steering deck and isn't in the operating reality, when role redesign is left as a post-go-live exercise. DEBCOR's standard pattern engages change management at the same time as the technical scoping: process design runs alongside blueprint, stakeholder engagement runs alongside vendor selection, value realisation metrics are agreed before the first sprint plan exists. The honest cost is small at this stage; the cost of catching the same issues at UAT or six months post-go-live is large.

Both, in a deliberate handover model. DEBCOR provides the senior change-management leadership, the methodology, the artefacts (stakeholder maps, communications calendars, training curricula, value-realisation dashboards), and the discipline through go-live. The customer's team owns the operating model on the other side — by design. Change management imposed by external consultants and then handed over rarely sticks; change management built jointly with internal owners who carry it forward does. The handover plan is part of the engagement from day one: which customer-side roles will own which disciplines after go-live, what the transition timeline is, and how DEBCOR stays available for post-go-live value-realisation reviews without becoming permanent overhead.

Three layers, agreed before the programme starts. First, leading indicators during the programme — stakeholder commitment scores, decision-velocity on operating-model questions, end-user readiness measured before each release, role-redesign coverage. Second, go-live indicators in the first 90 days — system adoption rates by role and module, support-ticket volume against forecast, business-process throughput vs. baseline, error rates on the transactions that mattered most in the business case. Third, value-realisation indicators at 6, 12, and 18 months — the specific KPIs in the original business case (close days, cycle time, NPS, productivity per FTE), reported against the baseline, with attribution analysis for which gains came from the system, which from the operating-model change, and which were never going to happen and should be retired from the business case. The standard is honesty about what landed and what did not — not narrative.

Yes — and AI is where change management is currently most under-invested. Activating Joule or a custom DEBCOR AI Platform agent without redesigning the surrounding work produces the same disappointing outcome as the traditional 'we went live but the business case didn't land' pattern: the agent runs, the team works around it, the projected productivity gain never shows. AI adoption needs the same four disciplines — process redesign for what the agent can now do, organisational change for which roles change and which retire, end-user enablement for how the human operators interact with agent output, and value realisation against the specific AI business case (close acceleration, dispute resolution time, AP cycle, customer-service deflection). DEBCOR's change-management track integrates with the AI delivery track from the start; the team owning the technical agent build also owns the adoption plan, by design.

Two reasons, and the first is honest. Most organisations have absorbed unrealised business cases for years without naming them — the system went live, the team called it a success, the productivity numbers in the original business case quietly disappeared from the executive scorecard. That worked when SAP delivery was the bottleneck and the business case was modest. The second reason is structural: S/4HANA and AI on SAP create capability the previous landscape did not have — clean core, agent-driven processes, real-time analytics, Joule across the suite — and the business case sizes have grown to match. The cost of leaving change management to chance has grown with the case. Programmes that built strong technical delivery muscle through ECC and S/4HANA are exactly the ones that benefit most from adding the change-management discipline now, before the larger AI cases ride on top of it.