How to tell whether an SAP consultant has really done the work

Every SAP resume lists modules, releases and well-known project names. Very few tell you what the person actually did. After screening SAP consultants for more than five years, these are the patterns we rely on to separate hands-on experience from proximity to it.

Ask about decisions, not definitions

Anyone can learn what a pricing procedure is. A consultant who has built one can tell you why a particular condition type was set as statistical, what went wrong with access sequences on their last project, and how they tested it. Good questions sound like:

• "Tell me about a configuration decision you would make differently now."
• "What broke in the first week after go-live, and how did you find the cause?"
• "Which integration point with another module gave you the most trouble?"

People who did the work answer with specifics: document types, table names, transaction codes, the name of the BAdI they used.

Pin down the release and the deployment

ECC and S/4HANA differ in ways that matter: Business Partner, the Universal Journal, embedded EWM and TM, Fiori. So do on-premise, RISE private cloud and public cloud projects. Ask which release the consultant worked on, whether the project was a conversion, a greenfield or a selective transition, and which phases they personally saw.

Separate configuring from testing

Many strong professionals have spent years testing SAP or supporting users. That is valuable work, but it is different from designing and configuring. Ask who wrote the functional specification, who did the configuration, and who signed off the test.

Check the technical boundary

For functional roles, ask how the consultant works with developers: can they read a debugger session, write a clear functional spec, understand an IDoc segment? For technical roles, ask about the business process the code supported. The best people on SAP projects understand both sides of the line.

Listen for how they handled the people

SAP projects fail more often on communication than on configuration. Ask how they ran a fit-to-standard workshop, handled a business owner who wanted a modification, or explained a cutover delay to leadership.

Verify with someone who was there

Where possible we speak to a project lead or manager from a recent engagement. Two short questions, what did this person own and would you work with them again, usually confirm or contradict everything else.

None of this replaces your own technical interview. It means the people who reach that interview are worth your time.