SAP Industries

The ERP core handles universal processes (finance, procurement), but each industry has unique needs, discrete versus process manufacturing, retail merchandising, utility billing, oil and gas logistics, public-sector budgeting. SAP packages these as industry solutions so customers do not have to build them from scratch.

• Manufacturing (discrete and process), automotive, high-tech.
• Retail and consumer products.
• Utilities, oil and gas, mining.
• Banking, insurance and financial services.
• Public sector, healthcare, higher education.

Industry solutions are not separate systems. Historically they were add-ons that had to be switched on, and the switch framework is still how you find out what is active: transaction SFW5 lists the business functions on the system and whether each one is on. Turning one on is often a one-way door, which is why it is a project decision rather than a config change.

What an industry actually adds is extra fields on familiar objects, extra document types, and sometimes whole new transactions. Retail adds article master data on top of the material master. Utilities adds the contract account and billing objects that a normal SD flow has no concept of. The base process still runs through the modules you already know.

Ten minutes, and it tells you what an interviewer means when they say the client is "on IS-U".

1. Run SFW5 and expand the business function sets. Note which are marked as on.
2. Check System, then Status, and open the component list. Industry add-ons appear there as their own components, for example an IS- prefixed entry.
3. Open a material with MM03 and look at the view list. Extra views, or extra fields on the basic data view, are usually the industry solution showing itself.

Doing this once teaches you the useful habit: before assuming a client runs standard SAP, check.

Combining a functional module (say SD or MM) with an industry (say retail or manufacturing) makes you far more valuable, because you understand not just the software but how a specific kind of business actually runs.

The pairing to aim for is one module plus one industry. An MM consultant who understands retail allocation, or an FI consultant who has closed a utility's books, is answering questions the generalist cannot. It also narrows the market, which cuts both ways: fewer roles, less competition, usually better rates. See SAP job roles for how those roles are actually advertised.

Abstract descriptions of industry solutions are not much use. Here is what three of the common ones actually change.

Retail adds the article master on top of the material master, because a retailer thinks in variants, a shirt in four sizes and three colours, rather than in separate materials. It adds assortment, allocation and season handling, and site master data where a normal system has plants. An MM consultant moving into retail spends the first month on article master structure.

Utilities adds a whole billing world the ERP core has no concept of: the business partner holds a contract account, meters are devices with reading orders, and billing runs on consumption rather than on a sales order. Order to cash as an SD consultant knows it barely appears.

Process manufacturing changes production from discrete assembly to recipes, batches and shelf life. Process orders replace production orders, batch determination becomes central, and quality inspection is not optional because the batch record is a regulatory document.

The common thread is that each one keeps the finance backbone and rebuilds the operational layer above it, which is why FI knowledge travels across industries better than logistics knowledge does.

There is no industry certification that substitutes for having worked in one, so the practical route looks like this.

Start from the process, not the product. Before touching an industry solution, learn how that business runs. A retailer buys in assortments and sells at store level. A utility bills a meter, not a customer. A pharmaceutical manufacturer cannot ship a batch without its quality record. Once the process is clear, the extra fields in the system stop looking arbitrary.

Read the master data first. Every industry solution shows itself in master data before it shows itself in transactions. Open the article master in a retail system, or the connection object in a utility, and you learn more in an hour than from a week of feature lists.

Use the vocabulary correctly. Industries are unforgiving about language. Calling a site a plant in a retail conversation, or a contract account a customer in a utility one, tells the room you have not worked in it.

Take the adjacent project. Nobody hires an industry specialist with no industry experience, so the entry route is a general role on a project that happens to be in that sector, and paying attention. Two projects in the same industry is usually enough to claim it honestly.

Expect the config to be opinionated. Industry solutions ship with a way of doing things, and fighting it is expensive. The consultants who do well are the ones who learn why the standard is shaped that way before proposing to change it.

The honest answer is that it pays later rather than sooner. A first job is easier to get as a general module consultant, because there are more of those roles and employers expect to train you. Industry depth starts to pay at the point where a client is choosing between two people who both know the module, and one of them already understands their business.

It also narrows where you can work. A utilities specialist is looking at utilities projects, and if none are running near you that is a real constraint. Weigh that against the rate, which is usually better, and against the work itself, which tends to be more interesting because the problems are less generic.

The sensible order is module first, industry second, and let the industry come from whichever projects you land on rather than choosing it in advance.

It is easy to read all this as though an industry system were a different product. It is not. The general ledger works the same way, procurement still creates a purchase order and receives against it, and the organisational structure of company codes and plants is unchanged. An experienced consultant dropped into an unfamiliar industry is productive within weeks precisely because eighty per cent of what they know still applies.

What changes is the layer the business actually touches: the master data it thinks in, the documents it raises, and the vocabulary it uses for both. Learning an industry is mostly learning that layer and mapping it onto machinery you already understand.

• Ignoring industry context, the same module differs by sector.
• Assuming standard config fits every industry, it often does not.
• Missing industry solutions and rebuilding what SAP already provides.

• Assuming an industry solution is installed because the client is in that industry. Plenty of manufacturers run plain S/4HANA. Check SFW5 rather than guess.
• Learning the industry before the module. The industry adds to a base process, so without the base you are memorising screens.

A number of industry solutions that used to be separate add-ons were folded into the S/4HANA core, so the old distinction between core and industry has softened. Others remain add-ons with their own release cycle. Check the component list on the system in front of you rather than relying on what was true in ECC, which is the same advice as everywhere else in the landscape.

Recognising the industry is the start, and configuring a process that carries its extra fields end to end is the part you do in the course.