A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
SAP hiring goes wrong at the first question, because “SAP consultant” describes two different jobs that rarely live in the same person.
A functional consultant configures a module to match how your business works. They know that a three-way match means something specific to your finance team, and they can express it in configuration. A technical consultant writes ABAP — reports, interfaces, enhancements, forms. Both are legitimate careers. Neither substitutes for the other, and job titles almost never make the distinction clear.
The second failure is confusing transaction-code fluency with process understanding. Someone can navigate a purchase order screen confidently and still not know why your process has three approval levels, or what breaks if you collapse them to two. Configuration should follow process. When it runs the other way, you get an implementation the business quietly works around within a year.
Which side of the split someone genuinely sits on, and whether they oversell the other. The most useful screening question in SAP.
Understanding why your finance close works the way it does, rather than only which transaction posts it.
Extending through released APIs and BTP instead of modifying standard objects. Decides whether your next upgrade is a project or a weekend.
Knowing which Z-programs to retire, keep, or rewrite. Most estates carry two decades of them and no inventory.
IDocs, BAPIs, OData, and CPI — plus what happens to a half-delivered document when the receiving system is down.
Brownfield conversion and greenfield build are different projects with different risks. Having done one does not mean having done the other.
The expensive SAP mistakes are not bugs. They are decisions that look reasonable at the time and turn out to be permanent.
Core modification is the classic. A requirement does not fit standard functionality, so someone changes a standard object instead of extending around it. It works, the business is satisfied, and the bill arrives years later at the next upgrade — every modification reviewed, retested, and often reapplied by hand. An estate with hundreds of them turns a routine upgrade into a programme with its own budget line.
Custom code accumulates the same way. Reports written for a manager who left a decade ago, interfaces to systems long decommissioned, enhancements nobody can explain. Nothing forces a clear-out, so all of it migrates forward. When a conversion finally begins, each object has to be assessed, and the assessment alone can run for months before a line of work starts. The organisations that handle this well are the ones that kept a live inventory throughout, and they are a small minority.
The subtler cost is configuration that fights the business. When a module was built to the process the business had on paper rather than the one it actually runs, people build workarounds — spreadsheets alongside the system, steps performed out of order, approvals given verbally and entered afterwards. The system reports what it was told, reality drifts away from it, and by the time anyone notices, the workaround has become the process.
Consultant (3–5 years). Configures within an established template, or writes ABAP to a specification. Has been through at least one full implementation or support cycle. Needs guidance on cross-module design.
Senior Consultant (5–8 years). Owns a module end to end, runs workshops with the business directly, and makes the configure-versus-build calls. Comfortable owning the integration points into and out of their area.
Solution Architect (8+ years). Cross-module design, S/4HANA roadmap, clean core strategy, and the standing to refuse a customisation. Worth the premium when the estate is large or a conversion is on the table.
S/4HANA conversion support. Custom code remediation and functional testing. The dominant request, and likely to stay that way for years.
Module configuration. FI/CO, MM, SD, PP, or HCM — usually driven by a change in the business rather than a new implementation.
ABAP development. Reports, interfaces, enhancements, and forms, plus retiring the ones nobody uses any more.
Integration builds. Connecting SAP to CRM, e-commerce, or a warehouse — and where three or more systems are in scope, a solution architect to specify what happens when one of them is down. See enterprise application services.
Application support. Steady-state cover for an estate that no longer justifies a full project team, usually alongside an internal lead who knows the history.
Authorisation and role redesign. Often triggered by an audit finding, and consistently underestimated because the technical work is small and the stakeholder work is not.
Week one. They ask about your process before they open the system. Expect the questions to go to the people who do the work daily rather than the people who own the budget — how an order really gets approved, where the spreadsheets live, what everyone has learned to avoid. Expect a written note of the places where configuration and reality have drifted apart.
Weeks two to four. On the technical side, an inventory of custom objects with a keep, retire, or rewrite recommendation against each. On the functional side, a shortlist of configuration changes that would each remove a workaround. Both should be small and specific rather than a transformation roadmap.
The warning sign is a consultant who never disagrees with you. SAP rewards standard process, and much of the value of an experienced consultant lies in telling you which requirement is a genuine differentiator and which is a habit worth dropping. Someone who agrees to configure everything exactly as described is selling you the next round of technical debt.
Hiring functional when you need technical. Or the reverse. Decide whether the work is configuration or code before writing the job description, because profiles on both sides will tell you they can cover the other.
Modifying the core because it is faster. It always is, in the moment. Extension frameworks and BTP exist so your upgrade path stays open, and that discipline only feels expensive until the first upgrade after you ignored it.
Treating a conversion as a technical migration. Brownfield moves your existing processes forward, including the ones that stopped making sense years ago. Greenfield forces a rethink and costs more up front. Choosing on technical grounds alone is how organisations spend a conversion budget and arrive at the same problems on a newer database.
Assuming module overlap. FI and CO are close. MM and SD are close. HCM is a different world, and so is anything sitting on SuccessFactors or Ariba. Ask specifically rather than trusting that an SAP badge covers it.
Rates depend on module, seniority, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.