What a key user is

Every SAP S/4HANA project needs people who know how the business really works and can explain it to the project, and who know how the new system works and can explain it to the business. Those people are key users. They are usually experienced employees from a department (an order desk lead, a senior buyer, a general ledger accountant) seconded to the project for part or all of their time. They are not consultants and not decision makers. They are the bridge.

At Contoso Motor Co., Maria leads the order desk for fleet customers. When the S/4HANA program started, she became the order-to-cash key user. Her job is to bring the order desk's knowledge into design, to check that what is built works for real orders from Great Lakes Fleet Services, to test it, to train her colleagues and to support them after go-live. She reports into the program for that work, while her process owner, Dan for finance and the sales director for order-to-cash, makes the business decisions.

What key users do

The responsibilities change by phase (lesson 2), but five threads run through the whole project. Key users represent their area in workshops, bringing real examples, volumes and exceptions. They validate designs and configuration against how the business works. They test, from early checks of configuration to user acceptance testing. They train, usually as trainers for their colleagues after being trained by the project. And they support, as the first point of contact for their colleagues in the weeks after go-live and often afterward as the department's SAP expert.

What key users are not

Key users are not the people who decide that the business will change how it works. That belongs to the process owner. A key user who agrees in a workshop to drop a customer-specific approval step has not made that decision for the company; they have made a recommendation that needs the owner's confirmation. Key users are also not unpaid consultants. They are not expected to configure SAP, although many learn to adjust settings in self-service tools in Public Edition projects. Keeping these lines clear protects the key user as much as the project.

Time commitment

The most common reason key users fail is not skill; it is time. A key user who is expected to do a full day job and attend workshops, review designs and test "in between" will fall behind by the second month. Projects that work agree the commitment in writing before the Explore phase: how many days a week, in which phases, and who covers the day job. Peaks come in Explore (workshops), in late Realize (testing and training) and in Deploy (cutover and go-live support). Contoso agreed three days a week for Maria during Explore and Realize, rising to full time in the six weeks around go-live, with a temporary colleague covering the order desk.