Key Considerations For Your HR Project
Key Considerations For Your HR Project
Key Considerations For Your HR Project
SAP HCM implementations impose additional demands on the data migration team. In order to ensure that your HR/Payroll project is successful, it is important to think through a few key challenges before your project begins the implementation phase. In this document, BackOffice Associates will focus on one of four key challenges that we see on every HR-Payroll implementation where we engage. With the right expertise and forethought, these challenges can be addressed in advance so they do not become disruptive.
Organization Structure
The Organization Management (OM) submodule is the foundation of any successful SAP HCM implementation. The data in OM describes all of the organization units and positions that exist across the enterprise. The organization units are arranged in a reporting hierarchy, and each unique position is situated in this hierarchy. Each position must be described with key attributes, such as the type of employee that should occupy it and the manner in which costs should be distributed. After go-live, the OM module provides your HR system a persistent backbone that endures across individual employee movements. HR data at the employee-level tends to be very transient. Employee movements are common and occur at their own frequency: people are hired, separated or transferred all the time. By contrast, the organization structure tends to be centrally administered and updated in a more predefined manner. Positions are usually authorized centrally, and reorganizations are administered with HR input. The OM module is extremely powerful and supports important functionality, including authorizations, workflow and manager self-service. However, very few clients have this information ready for SAP at the outset of an HR implementation.
Your database probably has less of your Organization Structure than you think: Most legacy systems do not exactly correlate to the SAP organization structure. Even when they are similar, it is almost always necessary to augment and validate the system. As a general rule of thumb, the legacy system will give you between 20% and 80% of the required information. In some cases, the team will begin with the required records but will need to add or update some key fields (e.g. official names to organization units). In other cases, the team will begin with a list of positions but will need to construct the organization structure from scratch using Visio diagrams. Usually, you will have enough data for the project to start on the right track, but it needs to be clearly understood that this is a baseline and not a complete data set. The organization structure will, in most cases, need to be constructed.
Key Recommendation #1
Assess the data assets that are available, but interpret them as a starting point. Do not begin by assuming they will be sufficient.
Example: PeopleSoft
PeopleSoft provides a good example of using legacy data as a starting point and then augmenting it. PeopleSoft systems have a department hierarchy and a supervisory hierarchy. The department hierarchy is closer to a cost center hierarchy in SAP. It provides a good initial structure if managers tend to have their own budget and cost center. However it may be managed at a higher-level than SAP will require in OM. The supervisory hierarchy exists at the right level of granularity, but it will not have organization unit names and it is not validated as strictly as SAP will require. In PeopleSoft, an employees supervisor can be blank, terminated or can create a circular chain. If you begin with departments, then plan on augmenting with lower-level organization units. If you begin with supervisors, then plan on cleansing the legacy data and augmenting with key vacancies and department names.
The Organization Structure will need to be actively maintained throughout the project: Once you identify the main data sources for the SAP organization structure, it is important to manage the augmentation in a structured manner from the very start of the realization phase. There should always be a central source of most-current data, regardless of how much data construction is required for your project. Beginning six to nine months prior to go-live, the test cycles will begin in earnest and they will require full data loads in rapid sequence over and over again. At each cycle, the data migration tea m will begin by getting the most-current organization structure and loading it into SAP, followed by all the active employees in this structure. If the OM data is not there, then the broader project team will not be able to test key aspects of the SAP system. Therefore, it is essential to start this collection early, and then to commit the right resources to maintain it throughout the project.
times during the course of a project. If it exists in a collection of spreadsheets, then the human element makes your loads highly error-prone. Sooner or later, someone will accidentally email the wrong version or load the wrong column, etc. Then the project will need to absorb a delay while the data is being remediated. Only use Microsoft Excel as a last resort.
Key Recommendation #3
If you need to use Microsoft Excel to collect the organization structure, then use it for initial setup of data very early in the project. When this is done, stop using it. At BackOffice Associates, we generally use our DataConstructionServer (DCS) for this purpose, but you can use the tool of your choice, as long as it can meet two key requirements: 1. Direct Maintenance: End-users should be directly constructing the organization structure in the tool of choice. Avoid versioning problems by eliminating remote copies. If you are using Microsoft Access, then use a single Microsoft Access. Do not allow five users to maintain five copies, because you recreate the same problem with a different tool. 2. Legacy Refresh: If the OM data is pre-populated from legacy, then there will be a desire to repeat this process periodically to get new hires, remove separated employees, etc. This refresh will need to merge new data with the collected data so it does not overwrite end-user changes.
Key Recommendation #2
Do not get blindsided by large-scale reorganizations that occur during your project, because they will increase the resources required to maintain your OM data. Work with the executive sponsors to ensure alignment. Maintain the Organization Structure in a database: It is important that the OM structure is built out in a database. The OM data will need to be loaded four, five or maybe six
HRBP
HRBP
HRBP
HRBP
Data Entry Interface Collection Store SOLUTIONS: Automated Refresh Data Entry Interface UI Validations Pre-consolidated
Contractors
FILTER
TRANSFORM
VALIDATE
Internal EEs
HR
Validate with the business: When you go-live with SAP, there are several key users who will see the organization structure for the first time. Frequently, they will see this not through a charting utility like Nakisa but indirectly through the functionality that it enables. SAP HR is designed to use this structure whenever possible because it offers a stable backbone for HR processes. Workflow will route approvals up the approval chain as defined by the organization structure. Security will restrict visibility to subordinates as defined by the organization structure. Compensation plining will allow you to setup budgets and bonuses for your department as defined by the organization structure. If the organization structure is accurate, there is a lot of great functionality that will work seamlessly. If it is inaccurate, the users will experience disruptions that are difficult to understand. In most cases, the legacy system will have no comparable functionality. Therefore the data in the legacy system will never have the same level of visibility to end-users. And it is never safe to assume that the business will regard it as factually accurate. Can you assume that a departmental reorganization three years ago was accurately represented in the legacy system? Probably not.
Key Recommendation #4
Distribute the collected organization structure to division chiefs for validation before migrating it. Request positive feedback and confirmation. It is important to plan out your validation process to include the business owners, and not just the core functional team. This activity should solicit positive confirmation from division chiefs or their direct designees. It needs to be planned out in advance with the right resources, training and tools. The validation resources should generally come from outside the core project team these need to be individuals who are directly familiar with the operating structure of the department, plant, or country. You should be engaging them very early in the implementation lifecycle compared to other end-users for the deployment. Remember, you will need a good organization structure for your first test cycles. Usually, this is far in advance of formal training and useracceptance testing. When you first engage, plan on doing some up-front education about SAP OM. As for tools, it is important to begin this exercise with (a) a standard method for distributing the organization structure and (b) an organized approach for collecting feedback.
The first is the easier of the two. In most cases, you can use Visio diagrams or load the OM into an SAP test client. However, then you must track all of the feedback. If input is requested from 30 different people, then be prepared to receive adjustments from 30 people. Establish a standard protocol or this will be challenging to manage. Each individual change must be faithfully represented if the exercise is to succeed. Repeat the end-to-end process until positive signoff is received.
Summary
In summary, it is important to consider a few key points at the beginning of your HCM implementation project regarding SAP OM. First, be prepared to augment your legacy data because it will very likely be required. Second, plan your resources around continuous maintenance of this organization structure from blueprint to go-live. Third, establish centralized tools to support the collection activities. Fourth, avoid Microsoft Excel whenever possible. Lastly, be sure to validate the organization structure with the business owners. Ultimately the organization structure will have far-reaching impact across SAP OM so it is essential to confirm its validity with the users who will be impacted.
BackOffice Associates, LLC PO Box 808, South Harwich, MA 02661 T +1 508.430.7100 F +1 508.430.7105 [email protected] www.boaweb.com
Copyright 2012 BackOffice Associates, LLC. BackOffice Associates, Boring Go Live and all associated logos are trademarks or registered trademarks of BackOffice Associates, LLC in the United States of America and elsewhere. Oracle and Java are registered trademarks of Oracle and/or its affiliates. SAP as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and several other countries. All other products, company names, brand names, trademarks and logos are the property of their respective companies.