SAP ERP fundamentals

Before ERP, finance, procurement, sales and manufacturing each ran separate systems, reconciled by hand. ERP unifies them so a single business event updates every affected area at once. Post a goods receipt and inventory, financial accounting and cost postings all update together, automatically and consistently.

The clearest way to see what integration means is to follow one event. A warehouse clerk receives a pallet against a purchase order and presses save. In a non integrated world that is one entry in a warehouse system, and finance hears about it later, from a document somebody carried.

In an ERP, that single action does all of this at once: the stock quantity rises, the stock value rises, an accounting document debits inventory and credits a goods received account, the purchase order records that this quantity has arrived, and the invoice that turns up next week has something to be matched against.

Nobody entered five things. One event, one entry, and every consequence recorded consistently. That is the whole idea, and everything else in an ERP is machinery for making it work.

The price of it is also worth stating early, because it explains a great deal about how these projects run. If one entry updates everything, then one wrong entry is wrong everywhere, and the controls that stop that are why an ERP feels rigid compared with a spreadsheet. The rigidity is the feature.

Where this idea lives in the system is the document. Every business event produces a document with a number, a type, a date and a set of line items, and documents reference each other. The chain those references form is the document flow, and being able to walk it is the practical skill that this concept turns into. A question like why does this account have this balance is answered by walking back down a document flow until you reach the event that caused it.

• Finance and controlling (the accounting backbone).
• Procurement and inventory (buying and stocking).
• Sales and distribution (selling and delivering).
• Manufacturing (planning and producing).
• HR, projects, and industry-specific processes.

What holds those areas together is the organisational structure: a set of units that model the business, and a set of assignments between them. The company code is the legal entity that produces a balance sheet. The plant is a place where materials are held or made. The sales organisation sells, the purchasing organisation buys, and the controlling area is where costs are managed.

These are not labels. They decide which documents can be posted, which numbers appear on which report, and what a user is allowed to see. They are also very difficult to change once the system is live, which is why they are designed in workshops at the start of a project rather than by whoever creates the first record.

The other thing worth saying about coverage: an ERP is not expected to do everything. Warehouses, transport, customer relationships, planning and analytics all have specialist systems that do more than the ERP module of the same name, and most large landscapes run several of them. The ERP is the system of record that the specialists integrate with, and understanding that boundary stops a great many arguments about whether a requirement belongs in it.

Two data types run through every ERP: master data (long-lived reference data like customers, materials, vendors) and transaction data (business events like orders and invoices that reference master data). This distinction, covered in its own lesson, is fundamental to how SAP works.

The practical consequence is that master data problems are expensive and transaction data problems are usually cheap. A wrong quantity on one document is one document. A wrong valuation class on a material is every posting that material will ever generate, in the past as well as the future, and correcting it means correcting the postings too.

This is why implementations spend so much time on data before go live, and why the phrase master data governance describes an ongoing function rather than a project task. Somebody has to own the rules for what a correct material record looks like, and somebody has to stop incorrect ones being created. See document types and the fiscal year.

The exercise that turns the definitions above into understanding, and it takes an afternoon.

1. Pick any goods receipt in a training system. Note the material, the quantity and the plant.
2. Open the material document it created. This is the logistics record.
3. From it, open the accounting document. Two lines: inventory and a goods received clearing account. Nobody typed these.
4. Look at where the account came from. It was determined from the material's valuation class and a configuration table, not chosen by the user.
5. Open the purchase order and find its history. The receipt appears there, and the quantity still outstanding has changed.
6. Now find the invoice, and see it clear the same goods received account the receipt credited.

Step four is the one that explains ERP. The user made a logistics decision and the financial consequence was derived from master data and configuration. Every argument you will later have about master data quality is an argument about step four.

Integration is powerful but demanding: it requires clean data, consistent processes, and careful configuration. That is exactly why skilled SAP practitioners are valued, they make integration deliver its promise instead of its pitfalls.

Worth naming the two hard parts precisely, because they are not technical.

The business has to agree with itself. An integrated system has one definition of a customer, one of a material, one of a cost centre. Getting three regions that have each run their own way for twenty years to accept one definition is the real work of an implementation, and it is not a software problem.

The processes have to be decided before they are configured. Configuration expresses a decision. If the decision has not been made, configuration becomes a series of guesses that get reversed, which is how projects lose their schedule.

The value is the other side of the same coin. When it works, the business gets one set of numbers that everybody uses, produced as a by product of doing the work rather than by a reconciliation exercise at month end. See SAP versus Oracle ERP for how the market's other large system approaches the same problem.

• Thinking of ERP as separate apps, its value is the integration.
• Neglecting data quality, integration amplifies bad data everywhere.
• Confusing master and transaction data.

• Treating master data as setup. It is the thing that decides what every future posting does.
• Designing the organisational structure late. It is nearly immovable once live data exists.
• Configuring before deciding. Configuration records a decision; it cannot make one.
• Expecting the system to be flexible. Integration and flexibility trade against each other. See Fiori fundamentals for the layer users actually see.

Version note: everything above is true of ECC and of S/4HANA. What S/4HANA changed is the data model underneath, most visibly by putting financial and controlling postings into one journal table, which removes the reconciliation between them. The concepts of master data, organisational structure and integrated posting are unchanged.

The concepts here take a week to read and a project to feel, and following a real process with somebody who can point at the configuration behind each step is the fastest way across that gap.