What Really Makes SAP End-User Training Work

Anyone buying SAP end-user training usually compares three numbers: daily rate, duration, number of participants. They appear in almost every proposal and can be placed side by side immediately — unlike most of what actually determines success.

None of those three numbers says anything about whether your people will be able to do their jobs after go-live. Two providers can quote the same price for the same duration and still deliver completely different results. What makes the difference is rarely stated in a proposal — you have to ask for it.

This article describes the characteristics that identify good end-user training, and gives you one question per characteristic to ask a provider before you sign. Why training fails is something I have covered elsewhere, in Why SAP FI Training Often Fails to Deliver the Expected Results. This article looks in the opposite direction.

First: why the usual metrics do not help

Duration. A three-day course is not better than a two-day course. It is longer. Whether the additional day brings hands-on time or additional slides is what determines the value — not the number itself.

Number of participants. Large groups are cheaper per head and therefore look better on paper. They also make individual practice difficult to impossible — and practice is the part that works. One important distinction: group size says nothing about a provider's quality. It is a parameter you set yourself, and it has a considerable effect on the outcome. There is a separate section on it further down.

The feedback form at the end. It measures whether participants enjoyed the day. That does not reliably correlate with whether they post correctly four weeks later. An entertaining training day with weak transfer scores well; a demanding one with a high share of hands-on work often scores worse.

These three figures are not worthless, but they are parameters — not quality criteria.

Six characteristics that reveal quality

1. The training is cut by role, not by module

An end user does not work "in FI". They enter incoming invoices, clarify differences or prepare the payment run. Training that follows SAP's module structure describes the software — not the work.

Good training is built along roles and process steps. Participants recognise their own working day in it, and everything outside their role is left out rather than included just in case.

2. Practice happens on your own system with your own data

Training on the standard model client shows how SAP works. It does not show how it works at your company. Your charts of accounts, your document types, your field control, your approval paths — none of it appears.

The difference becomes visible on the first working day after go-live: the participant looks for the field they saw in the training and cannot find it. Good training therefore runs on a training client with realistic master data and the company's actual processes.

That takes effort, and the effort is on your side: someone has to provide the client and create the practice data. A provider who raises this early is not selling you an add-on — they are taking the matter seriously.

3. Hands-on time is substantial — and firmly scheduled

Demonstrating is not practising. Watching someone enter a posting creates a feeling of understanding without building confidence. That only comes when participants click through it themselves, make a mistake and correct it.

As a guideline from practice: depending on the topic and its complexity, hands-on work accounts for 40 to 60 per cent of the training time. More is possible and often sensible — but only as long as the exercises are guided and supervised. Unsupervised practice time achieves little: someone who gets stuck with no one to ask will, if anything, practise the mistake. What also matters is that this time is fixed in the agenda, not left as a buffer at the end that gets cut first when time runs short.

4. The trainer can answer the subject-matter question

In every training session there comes a moment when someone asks not about the click path but about the why: why does this account require a cost centre? Why can I not change this document? Why does the system post automatically here?

A pure system trainer sidesteps at that point or refers to the consultant. More is lost than an answer: participants learn that asking does not pay off. A trainer with process experience answers the question — and that answer often sticks longer than the click path.

5. The materials survive the next release

Click-by-click guides with screenshots age quickly. A Fiori update moves a tile, a modification changes a screen, and the document no longer matches — with the result that nobody uses it any more.

More durable are materials that describe the process and the logic behind it, with the click path added as a supplement. They are still usable after the next release, because the business logic changes less often than the interface.

6. Success is measured against the work, not the mood

When training works, something observable changes: fewer queries reach the key users, certain error patterns become rarer, the ticket volume in the first weeks turns out lower than feared.

Such measures can be agreed in advance. A provider willing to discuss effectiveness criteria with you, rather than only satisfaction scores, has thought about the question.

Two parameters you set yourself

The six characteristics are things you assess in a provider. Timing and group size, by contrast, are your decisions — they say nothing about a provider's quality but influence the outcome considerably. Which is precisely why they belong in your own planning, not in the evaluation of a proposal.

Timing: three to six weeks before go-live

The gap between training and go-live is a balancing act. Schedule it too early and too much has been forgotten by the time it matters. From roughly two months' lead time onwards, the loss becomes clearly noticeable. Schedule it too late and there is no time left to consolidate what was learned or follow up on open points.

The window that has proven itself in practice is three to six weeks before go-live. Close enough for the knowledge to still be present; far enough away for follow-up work and additional practice in the test system to remain possible.

Group size: 14 to 22 participants

Group size depends on the situation, but it is not arbitrary. My best experiences are with groups of 14 to 22 participants. Large enough for exchange and for different perspectives from different departments, small enough to look over everyone's shoulder at least once during the exercises.

There is still a clear limit: an end-user training session should not exceed 30 people. Above that, the hands-on part can no longer be supervised, and anyone who gets stuck during an exercise stays stuck. If more people need training, the answer is another session — not a larger group.

And then: what happens after the training

The decisive phase is not the training itself but the weeks that follow. That is when what was learned meets real documents, real time pressure and cases that did not come up in the training. Why training matters precisely after go-live is something I have described using the example of the Fiori transition.

What typically happens then: users turn to the key users. But the key users are in the middle of their own peak workload — why they regularly struggle after go-live is covered in a separate article. The result is waiting times, improvised solutions and postings that have to be corrected later.

The FI Office Hours exist for exactly this gap. They start the day after go-live and taper off over time: three sessions a week of 90 to 120 minutes in the first weeks, reducing to two sessions a week of 45 to 60 minutes by weeks four to six.

The format is deliberately low-threshold. There is no agenda and no requirement to register a problem in advance. Any user can come and ask any question — including people who do not sit in finance but touch FI at some point in their work. Cases are clarified as participants bring them in from their desks.

The effect is twofold: the cases get resolved, and the questions raised in the sessions show precisely where the training had gaps. You will not get that information from any feedback form.

The checklist at a glance

Key takeaways

Price, duration and participant numbers are parameters, not quality criteria. What decides success is rarely stated in a proposal: role focus instead of module structure, your own system instead of the model client, real hands-on time instead of demonstration, a trainer who answers the subject-matter question, durable materials and agreed effectiveness criteria.

Two parameters say nothing about the provider but co-determine the result — and you set both yourself: the date three to six weeks before go-live, and a group small enough to accompany everyone through the exercises. And the most important question does not arise before the training but after it: who is available in the first weeks of live operation?

The good news for decision-makers: you do not need to know SAP yourself to judge quality. The questions in this article can be asked in any preliminary conversation. How a provider answers them says more than any proposal document.