Author Bio
The author is a SAP HCM subject Matter Expert since 1997 where he started in SAP. Niels Knuzen worked as consultant for SAP Nordic where he participated in numerous global roll outs and worked as instructor on the SAP HCM academies.
In 2003 he swapped to a nordic dairy company as SAP HCM architect. During these years he joined the global HCM customer group. In 2006 Niels Knuzen started his own company and has since been focusing on authorizations, identity management and security.
I will in this document focus on those thoughts you must give the organizational structure, and especially the enterprise structure and the personnel structure when you in an implementation decides what the different dimensions in these structures should represent:
Business considerations, which can have an impact on this decision is:
- The structures must reflect those dimensions we use for reporting
- The reporting structure (line of command) must be represented.
- The dimensions must be intuitive to use for our users.
- We want old systems dimensions to be reflected in SAP.
- We must be able to identify our senior managers.
- We must be able to identify, which countries our employees belongs to.
- Only data which are valid for an employee should be available for selection
---------------------------------------------------------------------------------------
Content
Author Bio
The three main SAP HCM structures.
The organizational structure.
The Structures used in Personnel Administration.
Validity of data
Authorization needs.
Reporting needs
Global vs. Local fields
Robust & Stable structures
Links to Videos for customizing enterprise & Personnel Structure
----------------------------------------------------------------------------------------
The three main SAP HCM structures.
OM: The organizational structure reflects the reporting structure where a line manager is in charge of his/ her employees O-S-P
PA: The enterprise structure reflects the company and locations. Functional aspects across country boundaries can also be reflected. This structure is Finance / HR combined structure.
PA: The personnel structure reflects the employees belonging to the company and how they should be handled according to time, compensation and payroll.
The organizational structure.
Figure 1: The organisational structure. The backbone for workflows.
The organisational structure should reflect the reporting structure so you don’t need to maintain this in an alternative structure. When the organizational structure reflects the reporting structure you can follow the manager’s area of operation with a drill down in the organisation from where the manager’s position is assigned.
When you are setting up the organisational structure please do it together with finance & Logistic since the organisational structure is used by all kind of workflows in SAP.
The organisation structure should also be closely aligned with the cost center hierarchy so you are able to assign cost centers to the structure. Keep the cost centers assignment on organisational units and handle deviations on positions only. Such a set up reduces the workload for cost center assignments.
If you decide to maintain the cost center assignment on positions level you must grant the employment handlers some LSMW tools, which will ease the operational work with the organisational structure and cost center assignments. I was during a review presented for a case where the cost centers where directly assigned to the positions and it swallowed 2 FTE’s work in a shared service center.
All active employees should be assigned a position for reporting, workflow and structural authorizations and this should also include externals. In some set ups HR has chosen not to assign hourly employees to the organisational structure because they considered the workload for keeping the structure up to date to high. This is a statement, which needs to be analyzed from case to case but please be aware of the missing benefits for not having ESS, workflows, reporting structure or structural authorizations for these employees. In one of my assignments the majority of the employees where not integrated with OM. My client had decided to implement structural authorizations and we were unaware of this situation until go-live. Hell broke loose since all the employees outside of the organisational structure where considered by the system as belonging to the default position. We managed the access to these employees through a customization of the default position in transaction OOAC, but the fine grained security set up we had planned went down the drain.
The Structures used in Personnel Administration.
In personnel administration we have the Enterprise structure and the personnel structure, which are the two main structures for grouping the companies’ employees according to:
- validity,
- security control and
- reporting
Figure 2 the enterprise structure.
Figure 3 The Personnel Structure.
Validity of data
The idea of creating structures is to group your employee’s logical regarding maintenance of talent, compensation, payroll and time management. With the Personnel Administration structures you can restrict the availability of data so it is only those entries, which are relevant for the employee, which shows up in drop down list. This functionality is known as data validity and helps employment handlers to pick up the correct data for our employees.
From a functional point the validity control is handled through groupings & indicators in the tables T001P_ALL for personnel subareas and T503_ALL for employee subgroups.
Figure 4 the groupings secure that only relevant work schedules pops up for selection. In this case the total amount of work schedules in table T508A was 449.
Authorization needs.
The master data structures, which includes: personnel area, employee group/ subgroup and perhaps the personnel subarea through the organizational key are all dimensions, which can be used in P_ORGINCON.
Business needs
- We need to restrict local administrator’s access to local employees.
- HR employees are not allowed to see each other’s data.
- HR partners must not access senior Mgt.
- Board members must only be accessed by HR Senior partners.
Figure 5 the fields: personnel area, employee group and employee subgroup are all standard available for authorization set ups. The personnel subarea can be customized to be part of the organizational key.
Reporting needs
Reporting is always needed and requirements for reports are endless. To fulfill the reporting need you should construct your master data structures, with as many dimensions as possible. When you set up enterprise and personnel structure with a wide range of dimensions you will be able to use each of them as selection fields in reports.
The dimensions for enterprise structure could look like this
Company code: Finance Result and Balance statement. This filed of the enterprise structure belongs to finance so they are in charge.
Personnel area could reflect site with an indication of country such as PL01, PL02 or US01, US02, where the first two characters indicate the country location and the last 2 characters the location. With this set up you also has the availability to search for ranges e.g. all employees belonging to Poland PL* or America US*
The personnel subarea could reflect cross country functional divisions or business areas such as:
- Power Products
- Power Systems
- Automation
- Low Voltage Products
Or
- Network
- Services
- Support Solutions
But when you decide on the master data structures please let each master data field reflect one dimension only. Otherwise you risk messing up the purpose of the data. e.g employee group representing values such as Permanent, External, Temporary and Director
In this set up where you have created a director in parallel with values such as permanent, externals, and temporaries you could be faced with an issue with a temporally hired director, because both values temporary as well as director matches this person. This example is for the purpose of keeping an eye on your dimensions and don’t mix them up because sooner or later you will end up with a contradiction in one of your processes.
Another argument for keeping your dimensions in master data in straight order is for easy roll outs. When you are training your employment handlers who are supposed to be trained and explained what to do, you will find it much more efficient to have straight dimensions, which represent one dimension and not several dimensions. Keep things simple!
Figure 6 the reporting uses the fields from HCM for selections as well as for outputs. With clear defined dimensions you can fulfill the need for many forms of reports.
Global vs. Local fields
Decide from the start which master data fields, you which to set up for global needs and which fields you want to use for local needs. In the enterprise structure, which consist of company code, personnel area and personnel subarea you can e.g decide that the personnel area are used for local purposes such as country locations and the personnel subarea are reserved from a global perspective to represent the company’s divisions.
I have already showed you an example of how to set up personnel subarea, so reporting across countries is possible. If you decide to let personnel area represent location then please reserve the country abbreviation on 2 characters for the first two characters in personnel area and then you can use the last to characters to describe the specific location in the country. This setup was particular useful when we needed to identify all the employees of a specific country since we could use search ranges such as UA* or FR* These ranges was also used for authorizations and when used as ranges we were independent of updating our roles when new production sites where created since they where already included in the range.
Another field which normally is global defined is the employee group, which in most set ups reflects a contractual relation to the company such as permanent, temporarily, external, or pensioner.
The employee subgroup is normally defined as a local field, but can be defined for global set ups as hourly employees vs. monthly employees or white vs. blue-collar. The fine grained set up on employee subgroups will depend on what kind of functionality you need for your employees.
If the implementations focus is reporting such as headcounts then you will find your implementation with 5-10 employee subgroups per country if you have payroll and time management in focus of the implementation you will see 20-40 employee subgroups per country depending on the legal demands and those union regulation you need to implement. In some of those implementations I have been through I have seen the employee subgroup used for identification of senior management. The CEO, CFO, CIO, presidents, Snr. VP’s was created with a single entry in the employee subgroup, which was reused across the countries. In these cases there was no restriction from the payroll side since they were all on individual contracts despite of different country assignments. This set up also help us in setting up the authorizations for senior management who could be separated from the rest of the employees based on P_ORGINCON and the employee subgroups
A rule of thumb is to implement the employee subgroup with space for further fine graining because it gives you the flexibility later to decide which subgroups you need to create for e.g. payroll or time management. Implementation of payroll will normally be handled country per country since each country have their own legal requirements and therefore SAP have separate payroll engines for each country (those countries SAP support with a payroll engine)
In some of the implementations I have seen the use of letters reserve per country (the IDES way) where D is reserve for Germany and S for Sweden or U for US. This gives us the employee groups D1, D2, D3 … DA, DB, DC ..DZ But this set up with reserving a start character per country have its limitation, since there are far more countries than letters in the alphabet J
In a global set up for the enterprise and the personnel structure you must avoid to have different dimensions for different countries. This could be for personnel subarea which in US is used for separating hourly and monthly employees and in China it is used for functional separation. In this case you can’t use the personnel subarea for global functionality such as reporting or authorizations. (Personnel subarea to be part of organisational key)
Robust & Stable structures
When you decide to create your enterprise and personnel structure please have future needs such as BizX & Success factor in your mind because new functionality might need finer grained groupings of your employees in regards of compensation, personnel development, time management or payroll.
When you decide your structures for enterprise and personnel structure don’t force old systems structures down the throat of SAP HCM. If you have a need for storing or mapping employees in SAP HCM so they are easily recognized with an old HR systems data then create these groupings and data in a customer specific infotype 9###. Here you can keep it for historical sake and transition easiness without any impact on the future enterprise and personnel structure.
Off course there can be an overlap with the old systems master data structures and the future structures you are defining in SAP enterprise and personnel structure and in this case it is fine to replicate the old systems structure. But a pure “cut and paste” from old systems structures to the new structures in SAP HCM should be avoided. The new structure you are defining must follow a plan and have a purpose. They must make sense.
The more independent your structures are the less impact you get from merging and split up scenarios. Because it is not only the customization of the master data structures, which must be planned in case of a merging or split up scenario. Your authorizations, all the features and the migration of those employees, which is affected, must be taken into consideration and then you have all the secondary impacts such as old report variants, training material, test documents, which need to be refreshed so they reflect the new situation.
In several set ups of the enterprise structure I have seen the personnel area copied 1:1 from the company code. This is in many perspectives a waist of dimensions and should be avoided. Don’t waist one of your enterprise structures most important dimensions on redundancy such as repeating the company code. Use it for another dimension so you can use it for reporting, the validating of data or authorization purposes.
Another redundancy which I have meet, is the mix of employee status and contractual relation, where the status Active, Inactive and Terminated from the employees infotype 0000 action is repeated and mixed in the field for employee group, which in most scenarios should reflect the employees belonging to a company. Keep the dimensions clean and straight and don’t mix them up.
references see the youtube video of this subject on these links
This video shows the customising steps for creating the enterprise and personnel structure.
This video shows tips & tricks for setting up the structures.
- SAP Managed Tags:
