A guide to hiring SAP developers
SAP runs the core of many companies: orders, stock, finance, purchasing and reporting. When something in it needs to change, a report, a form, a link to another tool, someone has to write and test that change without breaking the rest. That person is an SAP developer. Below you will find what the job covers, where it ends and other roles begin, and how to run the work with a remote hire. It is written for companies with a small SAP team and for those with none.
What SAP developers work on
Most SAP development falls into a few groups. Custom code covers ABAP programs, reports, forms and enhancements to standard processes. Screens covers Fiori and UI5 apps that give users a simple way to approve, look up or enter data. Integrations connect SAP to your online store, CRM, bank or warehouse tools. Data work covers loading master data and open items, cleaning old records and checking totals. Support covers the daily queue of errors and small requests. A developer may cover several of these, but most are stronger in one, so say which you need most.
Where SAP development ends and other roles begin
An SAP developer works inside the SAP landscape, with its own languages, tools and rules. If your system is NetSuite, Odoo, Dynamics or SAP Business One, our ERP developer page is the closer fit. A back-end developer builds the services and databases around your products, which is useful when the SAP interface talks to your own software. A software engineer is a broad role that covers many kinds of building, but not usually SAP in depth. Use the SAP developer page when the work happens inside SAP.
Who does what in a small team
- The business owner or process lead says what the company needs and signs off on the result.
- The consultant or analyst decides how the process should work in SAP.
- The developer builds the change, tests it and documents it.
- The basis or IT administrator looks after the systems, transports and access.
When one person fills two of these jobs, make it clear which hat they wear for each request. It stops a quick fix from skipping the test step.
Settle these points first
- The SAP version you run and whether a move to S/4HANA is planned.
- The modules involved, such as finance, sales, purchasing or stock.
- Whether the work is a project with an end date or an ongoing support queue.
- Which tools need to connect to SAP and who owns each side of the link.
- Who approves changes and who moves them into production.
Reading an SAP developer’s resume
A list of modules and tools says little by itself. Ask what the person built, in which version and what the result was for the business. Good answers name a real report, interface or fix, explain the problem and describe how it was tested. Be careful with resumes that list every module. Depth in the area you need matters more than a long list, and a short example of past code or a written description of a change tells you more than a title.
Interview questions to try
- Describe a custom program you wrote. How did you test it before it reached production?
- How do you check that a change has not broken a nearby process?
- What do you look at first when a user says a report shows the wrong number?
- How would you design an interface so a failed message can be found and sent again?
- Tell us about a request you pushed back on. What did you suggest instead?
Listen for real examples, with the system, the problem and the fix. Doubt anyone who says nothing ever went wrong in a release.
Set a short paid task
Give each finalist a short task that matches your system. Good examples are a small report with a clear spec, a review of a piece of custom code with notes on risks, or a written plan for an interface, including how errors are handled. Do the task in a safe test client, not in production. Pay for the hours. Judge the notes, the care taken in testing and how the person deals with questions about your process.
Match experience to the work
For small fixes and reports, a developer who is comfortable in your version and writes tidy code is enough. For a move to S/4HANA, look for someone who has handled custom code checks and testing in earlier projects. For interfaces, look for experience with the other tools involved, not only SAP. Job titles vary a lot, so ask which parts of a project the person was responsible for.
Access and a weekly routine
Give your developer access to the development and test systems first, and to production only through your normal release steps. Keep accounts in your own name and give no more access than the job needs. During the first month, meet weekly and go through each change together. Later, a brief written note every week is usually enough, in one fixed format so you can spot trends.
Fitting in with your own staff
SAP work goes well when the people who use the system are part of the conversation. Ask the process owner to review each request before coding starts and to test the result before it moves on. Ask your IT administrator who manages transports and release dates, so the developer knows the calendar. Keep a shared list of open requests, so everyone sees what is waiting and what is done.
Mistakes to avoid
- Letting a new developer work directly in production before they know your system.
- Skipping written specs, so the result differs from what the business wanted.
- Building custom code for something the standard system already does.
- Leaving changes undocumented, so nobody else can support them later.
- Letting a contractor hold the only copy of the access details.
Looking for help on another ERP platform? Read about how to hire ERP developers, or see our guide to building a remote ERP delivery team.