Preparing EC for Compensation implementation success

[xavierlegarrec]

Introduction

EC is going live first and Compensation implementation is planned for the following year: how can EC be built in the best possible way for Compensation ?

 

Recommendations

• #1 - Check on fields we recommend adding to EC without which we need to go through complex workarounds with custom MDF objects in Compensation implementations :
  
  
  • Comp Info > “Date of Last Salary Increase” (and also “Reason for Last Salary Increase” could be useful in Compensation eligibility rules).
  
  
  • Job Info > “Date made Executive” (date when employee goes from non-Exec pay grade to Exec pay grade).
  
  
  • Job Info > “Incentive plan” (which will populate on Save based on a business rule to be determined with Comp leads).
  
  
  • Employment Details > "Termination Reason (copy)". In case incentive payouts for terminated employees are based on termination reason, see explanations on this blog.
  
  
  • If the customer has EC without Position Management and would like to leverage the Document Generation feature to provide employees with self-service Compensation statements (vs the ones of the Compensation module that are generated by admins and stored on each employee's profile) in which they would like the Pay Ranges Min-Mid-Max values to show then this configuration must be implemented in EC (without this configuration Pay Ranges values cannot be queried by Document Generation - however they can be pulled into standard compensation statements thanks to the standard fields payRangeMin, payRangeMid and payRangeMax in the compensation module > design worksheet).
  
  
  • If the customer is planning on implementing Time Off module with a 1:1 relationship between Time Types and LOA Event Reasons (leading practice) then we recommend adding a custom string field in Job Info called "LOA Event Reason” with on Save Business Rule logic as follows in order to allow Compensation and Variable Pay templates to easily retrieve only specific Time Types as part of eligibility rules:
    
    
    • if jobInfo.Event = Leave of Absence, copy the standard EventReason field code into “LOA Event Reason”.
    
    
    • if jobInfo.EventReason = “LOAGLORTW” (usually the same code is used for all Return to work situations), make “LOA Event Reason” field blank.
    
    
    • More information in my comment here.
    
    
    

• #2 - Check with Compensation teams whether Pay Component Groups created in Comp Info are consistent with Compensation implementation requirements (what is considered Annualized Base Salary for each country, some countries add allowances for example).

• #3 - Make sure that payGrade is defined first (top line) in the HRIS-association for Pay Range in the Corporate Data model otherwise the standard Compa-Ratio integrated with EC Pay Range in Compensation module will not work. See this document.

• #4 - Make sure FO Pay Ranges table entries have all attributes entered (no blanks). See this blog.

• #5 - If one of the Foundation Objects such as Legal Entity is a key factor in determining eligibility for Comp processes then we recommend adding all comp processes as attributes of the Legal Entity to facilitate the implementation of Compensation Eligibility rules.

• #6 - Make sure Global Assignment cases have a unique field value for each situation. In simple designs the home/host field in EC Job Info is enough however when there are several types of work assignments a summary like the one here needs to be provided to the compensation consultant at the start of the implementation.

• #7 - Check that there is enough data history (one year) to run the first Variable Pay cycle.

• #8 - Start loading the Compensation Manager job relationship and hris-sync it with SECOND_MANAGER column of the UDF if Compensation approvers are different than the regular supervisor.

 

 

 

Conclusion and additional links

• Thanks to contributors from SAP: Christian Smith, Phil MacGovern, Anna Liebscher.

• Compensation Implementation Leading Practices is another blog related to this topic worth exploring.

• Are you a customer looking to understand the Compensation module better ? we would strongly recommend signing up for SAP's Embedded Launch Activities program so you can get access to your own Demo environment with leading practice configuration.

 

 

 

--

All the best
Xavier

 

(If you found this blog useful please consider giving it a Like)

[RamyaRaja]

Thanks for a well written blog, that sums up most of the scenarios at EC side.

Additionally, I would say 1. Think about relevant pay components to be added in advance (Of course we will have Basic salary and Bonus taken care of, how about R&R pay components?). 2. Think about additional job info fields to be added to create less complex eligibility rules, we call it Markers, to easily identify a group of employees who would be eligible(or ineligible) for the compensation process. 3. Think about where would you like to display the statements while designing People Profile. 4. If there are MDF objects getting created which could be relevant for compensation, ensure the settings are aligned with Compensation configuration. For data to be published back to mdf objects, it requires specific configuration set up.

[MVEL]

And one more from my side:

• If you have a promotion process deternminie which are the relevent event resons used and provised them in EC

[00022111734]

Thanks for sharing

[vinkamath]

All basic pay components should have the attribute 'Use for Comp Planning' set to 'Comp'.

[xavierlegarrec]

Yes that's a good one indeed. It is very important for customers using Periodic Planning - see link here) but it is actually also valid for customers doing Annualized planning as it can help in facilitating the design for Publish back (one xml code instead of having to hardcode each PayComponent for publish back). Please note here that EC data imports will fail when trying to load two recurring pay components both flagged as "Use for Comp Planning"= Comp for the same employee.

[xavierlegarrec]

Yes absolutely. In some cases when publishing back Customers will want to differentiate in the event reason what happened during the Comp cycle : Promotion and Adjustment or simply Promotion or simply Merit etc. The if-then rules need to be built as part of the publish back design in the Comp worksheets but there needs to be a corresponding event-reason in EC for each of the scenarios.

[xavierlegarrec]

Yes absolutely, your #2 is very similar to my number #5 above: sometimes there is no need for a brand new EC field with its own Business rule (which requires upload of data in initial data migration) but adding it as an attribute of a Foundation object goes a long way and easy for data migration. Regarding #4 in my experience these MDF objects requirements usually come up after the first compensation workshops and Compensation consultants need to know how to create them. One case I am working on right now for a very large organization is to create "Eligibility reports" that provide a way for planners through chatbot to easily know what is the reason for an employee's ineligibility to a specific comp process. For that I created a few MDF objects (one for each process) with Evaluate rules which breakdown the different parts of the eligibility in a friendly format that can be referenced by other modules (including GenAI ChatBots) and used directly as eligibility rules in comp templates. I've attached a screenshot here. But there are also many other use cases such as here, here or here.