Recommendation for an idiots guide to SAP

So our tiny little start up company has been purchased by a big huge massive company that is a front for funneling money to SAP consultants, or at least uses SAP a lot.
I am familiar with ERP systems from a ‘needs’ point of view but not at all familiar with the SAP specific lingo and structures and I have been told that the sooner I accept the way things are with SAP the happier I will be. I am sure a few people here have had to do battle with the beast of SAP, so does anyone have any recommendations for a beginners and intermediate guide or just words of advice/commiserstion and recommendations for a good whiskey.

ta muchly


I suggest you study diligently and get up to speed on all the new swear words.

PM Nava. I believe that is her vocation.

Well, not my vocation, I do it for money…

but yeah, if you want to PM or email me with specific questions I’ll be happy to answer. “Tell me about SAP” is a bit like saying “tell me about business management”… uh, which part are you interested in? Do you have technical questions or questions about specific modules? (“Modules” is what SAP calls the groups of screens of transactions intended for different departments, but it doesn’t really have a modular architecture, you get everything in a single database). About the technical side I only know enough to be able to get programmers to understand what I’m asking for; on the modules side I specialize in the Operations area but I’m familiar with the basics of pretty much all of them.

Maybe I should write a book! :smiley:

My company uses SAP for things like work orders and purchase requests, and I can kind of do some of those basic tasks I’ve been taught to do. (I’m still fairly new here.) But I don’t even know enough to know what questions to ask. Nevertheless, I’ll be keeping an eye on this thread to see if I can learn something from it.

And that’s why it’s difficult to even know which resources to point people to:

as an end-user, DrCube needs to know some things. Part of the things an end-user needs to know may not even be “standard SAP”; my current client’s personnel were stunned to discover how many of the things they thought of as “standard” were actually bespoke. They thought they were “standard” because they’ve been part of their SAP through four changes of factory ownership and because the company which originally moved the factory to “their” SAP considered those bespoke pieces part of their own “standard processes”.

A different end-user will need to know a different set of things. Someone technical, yet a different set. The OP mentions “structures”: that sounds technical (in SAP a structure is a bunch of tables which go together), but it could simply be the person who told him to get on with the New Times being snotty (they certainly do sound snotty). It wouldn’t be the first time someone drops a Big Word without having the fockingest idea what it means.

DrCube, “work orders” is, strictly speaking and in SAPish, Maintenance, but some people use the expression to refer to other kinds of orders such as Production orders. Which is your case?

User administration is ugly. When I have to set up a new user, I have to use the SAP application itself and two additional websites. No idea white it has to be scattered around like that. I can’t even imagine how awful it would be to actually use it.

The best thing to do is to ditch SAP and use Kinaxis RapidResponse instead.

It doesn’t have to. Those two websites aren’t part of the SAP setup, they’re something your company has added on. User roles can even be managed through a single transaction: the same one can be used to create roles and to assign them to users (verifying which roles a user already has is a different transaction).

Which is my main complaint about people complaning about SAP: 99% of the complaints are about the bespoke stuff!

Thanks all. I was looking for a book recommendation to get the big picture. The company basically runs their whole business (several 10s of billions revenue in oilfield services) through SAP, including manufacturing, sales, equipment management, people, beans etc.
I won’t be entering data or doing much, but would like to know enough to have a sense of why it’s such a big deal that a small operating location should or should not be a plant and why it’s such a big decision. That kind of stuff. I get it’s a big subject with a lot of company specific customisation so there’s probably no perfect answer, but if anyone knows a good book that would be awesome.

If you like videos, there’s a bunch of those in YouTube, I can look for some. I’m afraid I tend to disagree with every book I’ve ever encountered on the subject at very-fundamental levels (1); with the videos too but these tend to do less of the stuff that irritates me. Are you doing SAP R/3, SAP HANA, both?

Why it is important to have locations be their own plant is because a lot of data and security is managed at that level and because it affects how you move goods. In general it makes things a lot easier if each separate address is a separate plant; occasionally it makes sense to divide complex locations into several plants.

How does it affect goods movements?
A Plant can only have one address. So let’s say you need to move goods by truck from Location A to Location B. If both are Plants, SAP knows it needs to generate shipping documents; the processes to create those, load the truck, track the truck, go through Customs (if appropriate), transfer ownership (if appropriate), offload the truck, are all there. If they are the same Plant then both are at the same address and you need a Damn Big Bespoke Program to do the same thing.

How does it affect security?
Any piece of data which is created at the Plant level can be security-managed at the Plant level. Dumb-dumb example, but you can give to someone access to “all stock data from Plants A, B and C” (1 security object) more easily than to “all stock data warehouses 1, 2 and 3 in Plant A” (2 security objects); more importantly, you can track more easily which roles have which accesses if you only need to have one authorization object (indicate the Plant in the role’s name). The most efficient way to manage security in SAP is by having roles which are identical from Plant to Plant and separated only by Plant (i.e., all “warehouse operators” have the same accesses, but in different Plants; all “warehouse managers” have the same accesses, which are different from those of their operators, and have them for different Plants).

How does it affect other data?
Warehouse structures and most data objects belong to one Plant. A few objects (mainly Materials) can exist in more than one Plant and will have specific data for each of them: Material 12345678 could, for example, be inspected in Plant A but never inspected in Plant B: that is Plant-level data. How is cost calculated for a product, and the value of that cost: Plant-level data. Etc. The same Material will have other data which is Client-wide, such as its names in multiple languages, its dimentions, its EAN…

  • I was driving myself crazy retyping Plant as plant, but it’s a SAPish convention so I figured I’d explain it instead: if something can be both a “general concept” and a “SAP concept”, you capitalize to indicate you’re referring to the SAP concept and use small caps to refer to the general concept. A geranium is a plant and a factory is a Plant.

1a: any book or video will tell you that ERP is a type of software, but usually not why it’s called that. It’s called that in reference to a management philosophy (“Enterprise Resource Planning”), to the idea that in order to manage work correctly we need to take into account all of the resources involved and not only the materials (which is the idea behind “Material Resources Planning”, MRP). ERP software is software designed to enable that global management of resources.
1b: the people doing the videos tend to be better at pointing out “this is an example”.