GUIDING PRINCIPLES FOR CREATION OF THE SAP ENTERPRISE STRUCTURE 1. BUILD IN STABILITY.

The Enterprise Structure is the foundation of the SAP HR/Payroll System. The four key components of the Enterprise Structure are the Personnel Area, Personnel Subarea, Employee Group, and Employee Subgroup. None of these tables are date-delimited. Therefore, the Enterprise Structure should be as stable as possible over the life of the system. Data values that are likely to change frequently should not be included in the Enterprise Structure. Frequent changes in data values will cause frequent and possibly disruptive maintenance of the Enterprise Structure. 2. USE EACH CHARACTER WITH EXTREME CARE. The Enterprise Structure consists of only eleven characters: four for the Personnel Area, four for the Personnel Subarea, one for the Employee Group, and two for the Employee Subgroup. For most Public Sector organizations, more than eleven characters would be desirable. For large Public Sector organizations, eleven characters are very restrictive. Therefore, every character must be used with extreme care. 3. RESERVE CHARACTERS FOR FUTURE USE. Because the Enterprise Structure contains only eleven characters, some characters, and some character ranges, should be reserved for future use to accommodate changes in the organization or unexpected or unknown configuration requirements. It is advisable to reserve one character of the Personnel Area, one character of the Personnel Subarea, and one character of the Employee Subgroup for future use. Because the Employee Group has only one character, Employee Group assignment must be made with extreme care, and some Employee Group characters should be reserved for future use. Additions to the Enterprise Structure should be made prior to go-live, however. Additions after go-live, while sometimes necessary, are more difficult to accomplish. 4. LIMIT THE USE OF INTELLIGENT CODES. Ideally, intelligence would not be built into the codes of the Personnel Area, Personnel Subarea, Employee Group, and Employee Subgroup. Only one characteristic of the organization would be described with each of these codes. For example, the Personnel Area would describe only one characteristic, and the Employee Group would describe only one characteristic. However, because of the four component, eleven character constraint, this is usually impossible for public sector organizations, and becomes increasingly difficult for large public sector organizations. Therefore, it is necessary to describe two or even three characteristics using only one of the Enterprise Structure data elements. For this reason, intelligence must be built into the codes to some extent. For example, the first character of the Personnel Area can describe one characteristic, the second and third characters can describe another characteristic, and the fourth character can describe a third characteristic. Using the characters in this way by definition builds intelligence into the codes. This is unavoidable.

5. USE INTELLIGENT CODES WITH CARE. Despite the need to build intelligence into the Enterprise Structure, this should be done with care. For example, abbreviations for organizational names should not be used in the Enterprise Structure, because organizational names often change. Instead, nonintelligent codes (such as AA, AB, AC, etc.) should be used to denote organizational units, and the names should be put in the text descriptions of the codes. On the other hand, if meaningful codes are not likely to change, and if there is adequate room for growth, if codes are added, then it may be feasible to put codes with limited intelligence in the Enterprise Structure. 6. LIMIT THE NUMBER OF CODES. The primary purpose of the Enterprise Structure is to drive the rules for time, leave, benefits, and pay processing. A large percentage of all SAP configuration is tied in some way to the values in the Enterprise Structure. Therefore, in addition to insuring the stability of the Enterprise Structure, another extremely important consideration is to limit the number of codes in the Enterprise Structure as much as possible. Every code must be configured, so the more codes there are, the more configuration must be done, and the more configuration must be maintained. 7. DO NOT BUILD REDUNDANCY INTO THE ENTERPRISE STRUCTURE. Because of the desirability of limiting the size of the Enterprise Structure, there should be no redundancy in the Enterprise Structure. Do not replicate the information contained in other Enterprise Structure codes, and do not replicate information contained on other Organizational Management or Personnel Administration infotypes. Occasionally it is necessary to break this rule, but the reasons should be related to the need to perform special time, leave, benefits, or pay processing. 8. USE ONLY VALID COMBINATIONS OF CODES. Personnel Area and Personnel Subarea are always joined, and Employee Group and Employee Subgroup are always joined. Therefore, the number of combinations of Personnel Area and Subarea and Employee Group and Subgroup can become large. For example, 50 Personnel Areas and 50 Personnel Subareas yield 2500 possible combinations. Configuring and maintaining 2500 combinations would be a monumental task. Therefore, only valid combinations of Personnel Area and Subarea and Employee Group and Subgroup should be put into the Enterprise Structure. However, it is easier in SAP to combine Enterprise Structure values than it is to "split out" Enterprise Structure values at a later date. In addition, it is also relatively easy to group values to drive time, leave, and pay processing. Therefore, it may be advisable to include potential values in the Enterprise Structure, if these values may be needed in the short term.

9. HANDLE VERY SMALL NUMBERS OF EMPLOYEES MANUALLY. Valid combinations of these data elements that pertain to a very small number of employees also should also not be put into the Enterprise Structure. If a combination pertains to less than five employees, the first consideration should be to determine if the combination is actually valid, or if the employee has been placed in an invalid combination in the legacy system. If it is determined that the combination is valid, then strong consideration should be given to applying the rules for these employees manually, rather than through the Enterprise Structure. 10. DO NOT DRIVE REPORTING USING THE ENTERPRISE STRUCTURE. For a number of the reasons listed above, it is not advisable to drive reporting from the Enterprise Structure. Reporting should be driven from the organizational structure or from the cost center structure. Unfortunately, some standard SAP reports were originally designed to be driven by Personnel Areas and Personnel Subareas. If a customer needs these reports, they should be identified and analyzed individually to determine if there is an alternative method of producing these reports.