A lot of companies running SAP® solutions have difficulties properly maintaining their master data. For a large part the reason for this is that master data in SAP is dependent on the organizational structure of the company. If a company has a lot of different plants, purchasing departments, sales departments and other organizational elements, this fact is reflected in the master data. Makes sense! However, even if the organization itself is structured on a higher, less-detailed level, this does not always mean that the master data will get simpler.
An example could be when a company organizes its sales on a level that exceeds country borders, with one sales director and sales team covering an entire region encompassing a cluster of countries. This situation is quite common in Europe, where doing business “Europe-wide” has become much easier in recent decades due to the formation of the European Union and the Common Market. You might expect that the sales-related master data only needs to be maintained on this regional level. However, to understand why this is not always true, we need to dive a bit deeper into how companies are structured and how this structure is reflected in SAP.
The way the sales function is organized depends on the market, product and other factors. In practice this can lead to a variety of clusters. A grouping of countries could be based on a common spoken language: for example, the DACH countries – Germany, Austria and Switzerland, where the common language is German. Or sales regions modeled around economic, geographical or cultural groupings like the Benelux, which consists of Belgium, the Netherlands and Luxemburg.
The fact that companies organize themselves with regard to sales and logistics on this level does not necessarily mean that their legal structure can simply be altered to match. Still, at least in Europe, it is very common for companies operating in Europe to have legal entities in each individual country. For example, an ‘Ltd’ in the UK, a ‘bv’ in the Netherlands or a ‘bvba’ in Belgium. And these local legal and fiscal entities invoice their customers, have contracts, and most importantly have tax obligations and therefore need to keep their financial books in order.
Companies implementing SAP need to take of lot decisions when they customize their ERP system, one of them being the ‘real’ organizational structure in SAP. On the Sales and Distribution side, the Sales Organization is the highest level in SAP. The Sales Organization is the selling unit in a legal sense or could represent a regional subdivision. There is however one important thing to bear in mind: a Sales Organization is assigned to only one company or legal entity.
But what does this mean for an international company like Teradata which has legal entities in numerous European countries but organizes its sales function by combining countries? If Teradata was going to use an SAP ERP Sales & Distribution module, a different Sales Organization would need to be created for each country. This would have an impact on the master data, since it is used in the sales process: for example, materials need to be created on a Sales Organization level. This means that one product in the Teradata price list needs to be created in SAP one time on a general level e.g. description, stock keeping unit, and material type. Then this will also need to be created X times further with sales specific data; for example, the sales unit of measure. In theory this flexibility is great, if in one country bottles are sold in packs of six, then this could be the default for the Sales Organization for that country, whereas another country can default it to one bottle. In practice however if all the countries sell per bottle, it means an unwanted duplication of data.
Maintaining the master data can therefore become a very cumbersome job as an organization grows its product list and territories: each product will require its own master data in multiple instances. The maintenance is further hampered by the fact that it is impossible to see all the SAP master data in one place so comparisons can be made and errors easily spotted. From a maintenance perspective, it may be favorable, for example, to have one master data entry for each product, with exceptions for each country or legal entity.
We have worked with an international brewer that has a presence through a global network of distributors and breweries with operations in 71 countries around the world. They run 18 SAP ERP systems and other enterprise applications. Part of the project was to build a Master Data Quality Reporting solution to simplify the master data maintenance and reduce the errors that can inevitably occur when data is input manually.
The solution extracted all material masters, and programmed routines into reports which made it possible to easily identify master data issues. The result was that our customer was better able to maintain their master data despite having various Sales Organizations and numerous master data files for each product in their portfolio, helping them to be more efficient.
There are many ways to customize SAP which is one of the great benefits of the solution, the flexibility to arrange the software according to the unique configuration of your company. However, with this flexibility, a complexity issue often follows, which can make master data tricky to handle. Careful choices need to be made to ensure the customizations best match the organization both in terms of flexibility, and the ability to maintain master data.
A final thought: your master data is only as good as the rules that you apply to it -- which ultimately come down to good decision making. It’s key to carefully work out the ‘rule’ that ensures an optimal stock level for a particular product. For example, one will need to take into account seasonal variations, lead times, storage requirements and capital investment. And that’s where good analytics can really come in handy …. but that is for another blog!
Guest blogger Gert Jan Elemans is a Senior Software Engineer within Teradata Labs in the Netherlands. He has over ten years’ experience working with SAP R/3 and data warehouse environments and has won two awards for SAP implementations.