Change — Preparing the business

This is the eleventh article in the series "Inside a Large ERP Program." The last few chapters followed the data and the reports built on top of it. This one turns to the people who have to run what's been built, and to a pattern that starts long before the first training session.

Change management gets mistreated before it gets mismanaged. It sits on the plan, it has a lead, it shows up in the steering meetings, and it spends most of those meetings being talked over. This is partly a question of timing. When the build is still open and the design is still moving, a change consultant asking who's going to be trained and when reads as premature, an administrative concern raised while the real work is unfinished. So the stream gets a polite nod and very little authority, and the program tells itself it will get serious about change later.

It's worth being blunt about a second reason, because it shapes everything downstream. Change management runs on human skill more than on anything you can inspect, and human skill is hard to grade. A configuration is right or it fails a test; the verdict is external and quick. Change work has no equivalent. It's difficult to fail visibly at it, which quietly makes it the place a program parks a consultant who underdelivered somewhere the shortfall was measurable. No one plans this. It's a consequence of the fact that value on this stream is nearly impossible to assess in real time, so weak performance hides better here than anywhere else on the program.

That's the standing change management starts from. Everything that follows happens on top of that deficit.

Who actually becomes a key user

In a big organization the selection runs on availability: you get the people who can be spared, or who put their own hand up, and a department releasing someone for months is rarely releasing its strongest. There's a mirror image higher up, where the sponsoring executives treat the same transformation as a career move worth being seen on. The program is a springboard at the top and a staffing residual at the bottom, and the people sent to represent the business day to day come from the bottom.

What that produces is specific: a disengaged key user is a cost, but a key user who doesn't genuinely master their own process is a fault line. The requirements they give IT don't hold still, and it isn't because the business is genuinely undecided. It's because the person speaking for the business can't see their own process clearly enough to pin it down. IT then reworks the same requirement again and again, and reads the churn as scope instability when the source is a selection decision made months earlier and three steps upstream.

Even the right person, chosen for the right reasons, hits a wall that has nothing to do with capability.

The job they still have to do

The key user almost never gets to stop doing their real job. They carry the project on top of it, and when the two collide, the day job wins. It has to. The invoices go out, the customer gets an answer, the close happens on the calendar it always happens on, and none of that waits for a workshop. The project is the elastic thing in the schedule, so the project is what gives. A program that assigns key users without buying back a real share of their time hasn't secured their contribution. It has scheduled a conflict it will lose every time the ordinary week gets busy.

Training that works, and training that only reassures

The standard approach is train-the-trainer: you pick a set of users, put them through structured sessions, and rely on them to carry it to their colleagues. The material tends to be either slides or SAP Enable Now, and the gap between those two is wider than it appears. Enable Now is the more dynamic of the two, and for people who've never touched SAP, or who've only known the old back-end transactions, it does something slides can't: it lets them build a feel for how Fiori is meant to work instead of memorizing a sequence of clicks they'll have lost by next week.

But the deciding factor isn't the tool. It's when the training happens. Run it too far ahead of go-live and it evaporates before anyone applies it to real work. The remedy is almost embarrassingly simple: put the training right up against go-live, just before or just after, so the gap between learning the system and using it is measured in days, not weeks. Knowledge that gets exercised immediately stays. Knowledge that gets shelved does not.

Measuring readiness without lying to yourself

Programs reach for a questionnaire to prove the training worked, and a quiet distortion enters right there. The change managers scoring their own effort would rather the results looked good, so the questions drift toward the easy end. Adding more of them makes it worse, not better. Users already treat training as time stolen from their real work, and a longer survey just sharpens that irritation while telling you nothing more reliable than a short one would.

The honest signal isn't what people say about their own confidence. It's what they've already done. A trainer who sat through UAT has driven the system under something close to live conditions, and that's worth more than any self-assessment, because it happened under pressure rather than in a demo. When those trainers are also your testers, the order of operations becomes a lever: schedule their training just before UAT and the two events feed each other, one preparing the ground the other tests. You end up reading readiness off behavior instead of off a form, which is the only version of it that survives contact with go-live.

None of this reads as a crisis while the program is still not in production. It reads as one afterward.

Where the under-investment lands

An underfunded change stream stays quiet until go-live, then presents its bill to the two teams least able to defer it: the business, and the IT support desk. Support drowns in tickets filed as defects that are nothing of the kind, just users who were never properly trained reaching for the only help channel they can find. The business side produces a darker signal. People book sick leave to sit out the first period-end close, choosing absence over being the one who has to run a process they were never made ready for.

Neither is a technical failure. Both are the training and readiness work that should have happened weeks earlier, arriving late and wearing the disguise of an operational incident.

What to take from this

Strip these mechanisms down and none of them are really about how you train people. They're about decisions the program made without quite admitting they were decisions: who it sent to stand in for the business, whether it freed them enough to actually do the work, and whether it checked readiness against what people had done or only against what they'd claim. Bad training isn't what a program pays for at the end. It pays for choosing the wrong people to prepare, and for keeping change management too far from the table to object while there was still time to change course.

And yet, a program that makes every one of these mistakes can still come out ahead, because plenty of programs skip change management altogether and walk straight into the post-go-live problems this chapter has already described. Doing it imperfectly beats not doing it. The point isn't to hold out for a flawless change stream, it's to stop treating the stream as optional.

The next chapter picks up the moment all of this preparation, sufficient or not, has to survive contact with the switch itself: Cutover — Switching off the old system with no time left to fix a mistake.