Data Management

SAP NetWeaver ships with a mind bogging array of highly specialized applications to support different business processes. A SAP consultant will either interact with these applications or enhance them by writing new code to solve new problems during implementation. However, sometimes I feel that the real heart of SAP solution is not the code but the enterprise around which the code is built. The different application programs are just so many ways in which the users of the system can access the code. The power of SAP over the many legacy applications it typically replaces, is its one unified data model to store the different pieces of enterprise data. In a modern enterprise most data is inter-related and SAP leverages these linkages in its data design. However, since many of us, and this is all the more true of security consultants, do not directly work with data we lose sight of its importance in the bigger scheme of things. In this post, I would like to introduce to give a brief introduction the data management in SAP.

Business data in a SAP instance falls in any of the three following buckets.

• Enterprise Data or Organizational Data – This was the topic of the last post and even though I probably did not mention the word data even once, all the SPRO nodes which are used to build the enterprise structure are basically directly calling in SAP tables which store enterprise data. Enterprise data is the smallest but the most fundamental of the three buckets. All other business data is defined in relation to Enterprise Data. For example, the finance module in SAP talks a lot about ledgers and accounts. However, the ledgers and accounts themselves are set up for a particular company code.
• Master Data – Next in line is something we call master data. Master data are attributes of business objects which are relatively permanent in nature. They are not event or transaction based. Though there might be some disagreement between what constitutes master data and what not, no one would probably disagree on the items below. This is certainly not an exhaustive list
  • General Ledger Accounts
  • Customers
  • Vendors
  • Materials
  • Bill of Materials
  • Routings
  • Purchasing Information Records
  • Employee Personnel Records

•  Transactional Data – This is the last and the biggest of the three buckets. Every transaction or event that is recorded in SAP is part of transactional data. I would not even try to give a list for transactional data as almost everything that doesn’t fall in the other two buckets is likely to be a part of transactional data.

The three buckets can be visualized by the following graphic

At this point, the hard core security consultants among you might be thinking “Its great that SAP has three buckets of data. But now that I know the names of these red, yellow and blue buckets, how does my life change? Why would I care if there were ten buckets instead of three or maybe a single bucket called DATA?”

To a certain extent I would agree with you. For many of us busy with our regular duties of creating roles, users, assigning these roles to users and then locking these users so that they can no longer login to SAP 🙁 it really doesn’t make a difference. And probably no interviewer would be ever asking any of us about the importance of data management so it should be doubly irrelevant to us. However, I take the opposite view and anything that makes us better consultants is worth understanding. So here are the counter-arguments

To a very large extent security in SAP is data driven rather than application driven. So irrespective of whether we use transaction XYZ or ABC, if both these transactions touch the same data chances are the security objects that are needed to make these two transactions work would probably be the same. No where is more evident than in HCM as there are probably a handful of objects which control access to the entire set of personnel administration transactions. There is a post on the different types of HCM data else on this blog and I would not want to repeat myself here. In fact I would stick out my neck and say that its not possible to be a good HCM security consultant unless you are familiar with the underlying data model. Though the data driven nature of security is not readily apparent  in the other functional areas but that is more a result of the multitude of different authorization objects rather than a breakdown of  SAP’s logic.

The second logic why understanding the different types of data is important for security consultant is its use in the basic principles of access controls. The fundamental principle of most segregation of duties risks is that a single user should not simultaneously have access to update master data and also execute transactions which are based on the same master data. The classic example of the above principle is when a person has access to update customer records and  create sales orders, he can give his buddy (or even himself) a better rate than the company sets. If the security consultant is aware of these risks, he can raise a red flag during designing roles instead of the waiting for the risks to be identified in production after the loss of a few millions in fraud. So take your pick………….Learn today or Fix tomorrow!

In the rest of the following posts in this section, I plan to concentrate on the different master data and transactional data tcodes and talk about the security options provided for them. Hopefully they would be useful.