SAP Customers

SAP is used by a large majority of the biggest global companies, across virtually every industry, plus many mid-sized firms and public-sector bodies. These organisations run their finance, supply chain, manufacturing and HR on SAP, often as the single system of record for the entire enterprise.

One qualifier on the numbers that get quoted: counts of customers include everything from a global manufacturer running a dozen systems to a mid-sized business on a cloud edition, and the two have almost nothing in common as places to work. The useful question is not how many customers there are but what share of them run the product and the edition you are learning.

• Depth and integration: one system covering end-to-end processes.
• Industry solutions: tailored capabilities for specific sectors.
• Scale and reliability: proven at the largest transaction volumes.
• Global reach: multi-country, multi-currency, multi-language, compliance built in.

A useful correction to the idea of "a company runs SAP": almost nobody runs one system. Knowing the typical shape tells you what a job is likely to involve.

At the centre sits the ERP, S/4HANA or still ECC, carrying finance, procurement, sales and often production.

Around it, line-of-business products: SuccessFactors for HR, Ariba for procurement, Concur for expenses, and a customer experience product for sales and service.

Alongside those, analytics, a warehouse or a cloud analytics tool, and integration, some combination of PI, PO or Integration Suite.

And around all of it, things that are not SAP at all: a warehouse management system, a manufacturing execution system, a treasury platform, a payroll bureau, dozens of smaller applications.

Two consequences follow for anybody working in this world. Integration is a large share of the work, because a landscape of eight systems has more interfaces than any one of them has configuration. And hybrid is normal: cloud and on-premise side by side, with different release cadences and different rules about what can be changed.

SAP customers tend to run complex, highly-customised environments with long lifecycles. That complexity is why implementations are substantial projects and why experienced consultants are in demand to configure, migrate and support them.

It also shapes what the work feels like. Long-running systems accumulate customisation, and a great deal of consulting is understanding why something was built before deciding whether to keep it. Change is slow because the system runs the business, and testing is proportionate to that. And decisions involve more people than the size of the change suggests, because a field on one screen touches four departments.

The customer profile decides the shape of the market, which is worth knowing when choosing a direction.

Large enterprises run the systems, so in-house roles exist in finance, IT and shared service functions, and they tend to be stable, deep in one landscape, and less travel than consulting.

Consultancies and partners deliver the projects, which means implementations, conversions and rollouts, more variety, more travel, and exposure to many landscapes in a few years.

Mid-market is growing through cloud editions, and that work looks different: faster projects, less configuration depth, more fitting the business to the standard.

Support and managed services is where a great many people start, and it teaches cause and effect faster than any course because you see real incidents.

The through-line is that the customer base is large, established and slow-moving, which makes this a durable skill set rather than a fashionable one. See what SAP is for the foundation and SAP against Salesforce and against Workday for the comparisons buyers make.

The single most useful fact about the customer base for anybody planning a career: a great many organisations are still on the previous generation, and the migration is the work of this decade.

That produces three kinds of engagement, and they want different things.

Conversion projects take an existing ECC system to S/4HANA in place. They reward people who understand the old system as well as the new, because the hard part is deciding what to carry and what to leave.

New implementations build fresh, often in the cloud, and reward people who can run a fit-to-standard workshop and hold the line against unnecessary customisation.

Run and optimise keeps existing systems working, and it is where most people are employed and where the deepest product knowledge is built.

The maintenance deadlines for the older generation are the forcing function, and they mean this work is funded and scheduled rather than discretionary. For somebody choosing where to specialise, that is a more reliable signal than any product announcement, because a deadline in a contract moves budgets and an announcement does not.

Understanding the purchase explains a good deal about how projects behave.

Licences or subscription. Traditionally a perpetual licence plus annual maintenance; increasingly a subscription that bundles software, infrastructure and some services. The second changes the buyer's incentives, because the cost recurs and is renegotiated.

Implementation services, usually from a partner rather than from SAP, and typically a multiple of the software cost. This is where most consultants are employed.

Infrastructure, either their own or included in a cloud arrangement.

Ongoing support, in house, outsourced, or a managed service.

Two consequences worth knowing. Projects are approved as a business case with benefits attached, so scope creep is resisted at a level above the project team, which is why fit-to-standard has commercial force rather than only technical merit. And the software is a fraction of the total, which is why a decision that saves licence cost and adds implementation effort is usually a bad trade.

Understanding who delivers projects explains most of the job market.

SAP itself sells the software and delivers some services, and it is not where most consultants work.

Global systems integrators run large programmes for large customers, with big teams and structured methods. Good for learning method and scale, and roles are often specialised.

Regional and specialist partners deliver mid-market and focused work, where one person covers more ground and learns faster as a result.

Independent contractors fill specific gaps, usually after years of experience, and this is where deep specialisation is paid for directly.

Customers themselves employ in-house teams to run and improve their systems, and this is where the deepest knowledge of one landscape is built.

For somebody starting, the useful observation is that these have different entry requirements. Large integrators recruit graduates and train them; specialists usually want experience; in-house roles often recruit from their own business rather than externally, which is why an internal move from a finance or warehouse role is one of the most reliable routes in.

• Assuming SAP is only for huge firms, mid-market editions exist too.
• Underestimating industry specificity, sectors have distinct SAP solutions.
• Ignoring global/compliance complexity, a core reason large firms pick SAP.

• Assuming one customer means one system. The landscape is the unit, and integration is where much of the work sits.
• Expecting cloud customers to behave like on-premise ones. The constraints and the release cadence change what a project is.
• Reading customer counts as market opportunity. See the SD customer master for the unrelated technical sense of the word customer, which is what most searches for this term actually want.

• Judging the market by product announcements. The installed base and its maintenance deadlines decide where the funded work is, and they move more slowly and more reliably than the roadmap.

Knowing who runs SAP is context, and working inside a real landscape with its integrations and its history is the part you do in the course.

The thing to hold from this page: the unit is the landscape, not the system. Almost nobody runs one, integration is a large share of the work, and hybrid cloud and on-premise side by side is the normal shape rather than a transitional one.