What does an SAP functional consultant do?

An SAP functional consultant owns one business area of the system — Finance (FI), Sales (SD), Procurement (MM), Manufacturing (PP) among them — and shapes the standard software to the way a company actually runs that process, mostly through configuration rather than code. The role runs the length of a project, from the design workshops at the start to the weeks after go-live.

From fit-gap workshop to hypercare

Fit-to-standard workshops. The classic fit-gap: sitting with the business, mapping how the process runs today, deciding what the standard covers and what it doesn't.
Configuration. Turning those decisions into customizing — company codes, document types, pricing procedures, order types — the deep settings that make one standard system behave like a different company at every client.
Functional specs. Where the standard genuinely ends, writing the spec a developer builds from — and testing what comes back.
Testing, training, cutover. Test cases with the business, key-user training, data validation, and the go-live weekend itself.
Hypercare. The first real close in the new system, the defects only live data finds, then the hand-off to AMS.

Which of these fills a given week is set by the project phase, not by the role: a design week and a test week barely resemble each other.

What does "configuration" actually mean here?

It means setting the software's own switches so that standard code produces one company's behaviour — work done in the Implementation Guide and its tables, not in a programming editor. That is the whole reason the role exists as something separate from technical work.

Concretely: org structure (company codes, plants, sales organisations), document types, pricing procedures and account determination, approval steps. Configuration is not typed straight into production: it is collected into transports and travels the system tiers, development to test to production, by the same route a developer's code takes (the working vocabulary).

Who a functional consultant sits between

This is a translation seat: business language on one side, system behaviour on the other, and most of a day spent making the two agree.

Process owners and key users: Where requirements and sign-off come from — and the seat many consultants started in themselves.
Developers and integration: The spec hand-off, and the retest when the transport lands in the test system.
Security and authorizations: Who may post, release and approve what is a design question inside the area before it is a roles-and-profiles question.
The architect and the project manager: Cross-area decisions and dates; the consultant supplies the effort behind each option and what it costs the process (how architects decide).

Process depth, and the discipline of not building

Process depth, not menu knowledge, is what separates one consultant from the next. A great FI consultant can close a month; a great SD consultant can explain the order-to-cash flow to a CFO without touching a keyboard. Debugging skill — reading code without writing it — is the quiet multiplier: it turns "the system is wrong" into a sentence a developer can act on.

The other separator is restraint. Knowing what the standard already does before designing around it, and being able to say plainly what a custom development will cost at every future upgrade, is what clean-core practice made part of the job description.

The second area, and the seats after it

Deep specialists stay valuable, and a second area next to the first is the usual first widening (which combinations pay off). The broader path runs to solution architect or into delivery and leadership. Sideways moves are just as ordinary: into an in-house team that keeps one system for years, into support, or into freelancing once the record is long enough to sell.

What carries across all of those is the record itself — which area, which role, which projects — worth stating precisely on a CV and on the SAP World Map.