If you are a member of a team of business analysts in charge of a mid- to large-scale R/3 system, then you are very aware of the importance of a well-designed R/3 organizational structure. The org structure design has ripple effects that influence a number of processes positively or negatively depending on the quality of the design. It affects your reporting capabilities, ease of business process design, master data maintenance, authorizations and security, and many other areas.

Creating and maintaining a good R/3 org structure design is not a simple task. Requirements might not have been clear when the org structure was set up at the early implementation stage. Furthermore, various org structure options are not well understood.

It is also likely that the requirements have changed over time. For example, purchasing departments might have been centralized to eliminate the need for separate purchasing organizations for each location. Perhaps sales organizations were reorganized. Consequently, the org structures at many companies are not set up in the best possible way.

Whatever the reason may be, changing an already established organizational structure is not an easy task. Since every document, line item, and posting is assigned to multiple org structure elements, and historical transactional data can not be restated, changing org structures in midstream is next to impossible with conventional methods. As a result, companies often maintain a less-than-ideal status quo for a long time.

I recently helped one company consolidate 14 sales organizations into six as well as five purchasing organizations into one. The method that we used was unconventional and relied on a custom-developed toolset. I will explain how we did it in the hope that you might find the approach useful in your situation. First, let me review the conventional method to change org structures in midstream.

The Conventional Method

The conventional method is to set up a new structure in addition to the old (and obsolete) structure. You then gradually retire the old structure by letting the existing and still active data assigned to the old org elements "die out" while assigning all newly created documents to the newly defined organizational elements.

You typically control the process by adjusting the authorization profiles of users such that they have only display and change privileges for old organizational elements. This ensures that new documents are created with reference to only the new organizational structure, allowing the old structure to become completely inactive over time.

The disadvantage to this method is that it creates a shift in the historical data, making reporting and comparisons difficult. This is because the shift usually does not happen on a certain date; it happens gradually as existing transactions are "flushed out" — e.g., you would set up your new structure of sales organizations and sales offices and would pick a cut-off date on which you would start creating sales orders against the new structure. You would still have to process already existing sales orders that are in progress.

Realigning the Old with the New

The unconventional method we used to realign all or a subset of historical transactional data to a new organizational structure uses a set of custom-developed programs that we refer to as the "data conversion toolset." The main idea behind this approach is to technically modify the data records based on carefully defined conversion rules. Here are the steps for the example of consolidating sales organizations (Figure 1):

Figure 1

Sales orgs 2000 and 2010 are consolidated as sales org 2000

Step 1. Identify the technical object that needs to be changed. In our case, it was Sales organization represented by the technical domain VKORG.

Step 2. Define the logic of the "conversion rule." The conversion rule can be a simple 1:n mapping (a 1:1 mapping would result only in renaming or recoding the sales organization) as shown in Figure 1, or it could be implemented as custom code for more complex conversion requirements.

Step 3. Implement the conversion rule (mapping table or custom code) in the toolset.

Step 4. The toolset assisted us in identifying all database tables that reference VKORG — for example, the sales order header table VBAK (Figure 2). This step is of utmost importance to ensure data integrity after the conversion. This is done by using the toolset's "where-used" function, which identifies all table fields assigned to the data element or the domain VKORG.

Figure 2

The toolset helps identify all tables that reference technical domain VKORG

In a typical R/3 implementation, you might get a list of approximately 600 tables for this example. The number varies based on condition tables, Controlling-Profitability Analysis (CO-PA) tables, information structure tables, and so on, that might have been added through customizing.

Step 5. The conversion rule can now be automatically or manually assigned to all or selected table fields identified in the last step.

Step 6. The toolset automatically generates an ABAP conversion program for each table that the conversion rule was assigned to in the previous step. The conversion rule is embedded in the conversion programs. The conversion programs follow a simple logic as follows: sequential read of the table, modify the data record according to the embedded conversion rule, and update the data record.

Step 7. All conversion programs are scheduled to run as background jobs.

The end result is a technically converted data basis reflecting the changed organizational structure.

Dangers and Limitations

This method changes many data records without applying any functional validations, so the danger of corrupting the data integrity is great. If carefully used, however, you can apply this approach to many different problems that would otherwise be very difficult to solve.

You could use this method for any data object for which R/3 does not offer a standard way of changing that needs to be changed. The applications can be as simple as a straightforward 1:1 renaming or renumbering of an object such as a material number (e.g., for data harmonization purposes) or complex processes such as conversion of a general ledger chart of accounts.

However, this approach has limitations. It is successful only if all references to the converted data object are found and converted correctly. Also, the "where-used" function has these limitations:

• Usage of one and the same domain for one object is not consistent across the entire R/3 data dictionary. The same data object is sometimes assigned to a number of different domains or data elements depending on when and by which development team it was created. For example, "language" is sometimes defined with the domain LANGU and sometimes with SPRAS. A search of all table fields assigned to SPRAS, therefore, will provide an incomplete list. Dealing with cases like this requires additional manual steps.
• In many areas of the R/3 data model, generic character fields are used that can hold many different objects of many types. One example is the field OBJECTID, which is part of the key of the change documents header table CDHDR. This field can potentially hold the ID of any objects for which change documents are generated.
• The conversion process could, depending on the size of the R/3 database, be time intensive.

Table 1 compares the conventional method to the method introduced here. This process is, without a doubt, an intrusive operation that should be applied with the utmost care and lots of testing. It should not be used if there are less-intrusive alternatives. It does, however, make possible changes and realignments that would otherwise be impossible.

Ali Sarraf

Ali Sarraf is the managing partner at Enowa Consulting. He has 15 years of experience as a senior consultant for SAP Business Suite applications and 20 years of IT experience. During much of his career, he has focused on helping customers optimize their logistics business processes by analyzing and explaining cause-and-effect relationships and by bringing the machine and the human sides of IT closer together.

You may contact the author at ali.sarraf@enowa.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.