Hire SAP Functional Consultants

The most expensive decisions on an SAP programme are made before anyone writes code, and they are made by functional consultants. Whether a process is configured or extended, whether a site is modelled as a plant or a storage location, whether an approval is a release strategy or a workflow — each of these is cheap on a slide and structural in a live system.

What separates a good functional consultant from a certified one

What separates a good functional consultant from a certified one is what they do with a requirement that does not fit. The weak response is to log a gap and pass it to the technical team, which is how estates accumulate hundreds of enhancements nobody can upgrade past. The better response is to establish whether the business process is genuinely a business requirement or the way one person has always done it — and a surprising amount of the time it is the second, and the gap disappears.

Why the specification is the deliverable

The second thing that matters is the specification itself. “The system should allow the approver to reject” is not a requirement; it is the title of one. Who approves, on what basis, what happens to the document afterwards, what the next person in the chain sees, and what an auditor can reconstruct six months later — those are the requirement, and if the functional consultant does not write them down the developer will invent them.

A functional specification is finished when a developer can build from it without asking a question that changes the design, and a tester can write a case that fails. Anything short of that is a statement of intent that will be reopened in the third week of testing, when the cost of reopening it is a change request rather than a conversation.

Where fit-gap analysis goes wrong on a real estate

Fit-gap is usually run as a workshop series and scored as a spreadsheet, which is where it goes wrong. A gap raised in a workshop is a gap asserted by whoever spoke loudest in the room, and the list that comes out of it becomes the RICEFW backlog for the rest of the programme. Nobody revisits it, because by then it has a number.

The discipline that avoids this is evidence before agreement. Before a gap is accepted, someone should be able to say how often the case actually occurs in the current system, what the business consequence is when it is handled manually instead, and which standard SAP process was considered and rejected. Roughly speaking, a gap that cannot survive those three questions is a preference, and preferences are the cheapest thing on a programme to give up.

What cutover asks of a functional consultant

Cutover is where functional configuration stops being theoretical. Opening balances have to be loaded and agreed, open purchase orders and sales orders have to be represented in a system that models them differently from the one they came out of, and every one of those decisions is a functional one that a data migration team cannot make on its own.

The consultant’s job in that window is to define what a correct result looks like before the load runs: which control totals will be compared, what a permitted difference is, and who signs. Mock loads exist to find that out early. A programme that reaches its dress rehearsal without a reconciliation definition has not tested the migration, it has only tested the loader.

What we interview for

We interview on judgement rather than transaction codes, because the transaction codes are the part that is easiest to learn and the least predictive of outcome.

• A process the candidate has configured, and the one decision inside it they would now make differently
• How they establish whether a requirement is a business rule or a personal habit
• A specification they wrote that a developer built without coming back for clarification
• What they did on a cutover weekend, and what went wrong on it

When you do not need a functional consultant

If the process decision has already been taken and documented to the level a developer can build from, you need technical capacity, not functional capacity — and adding a consultant at that point adds a review layer rather than a decision. Equally, a small change inside a module your own team configured and still understands is faster done in-house than explained to somebody new.

The case for staffing this role is a programme where nobody currently present can say why the system is set up the way it is, or one where the same argument between two departments has been reopened three times without resolution. That is a functional problem, and no amount of development capacity will close it.

We staff functional people to sit next to the technical ones rather than upstream of them. A specification that has never been read by the person building it is a document, not a design, and the difference shows up in the third week of testing.