Thought I would share a few lessons learned around Compensation management using SAP ECM (Enterprise Compensation Management), but these could be used for any compensation system.

1. ECM supports the annual compensation (“focal review”) process, but not the off-cycle (ad hoc) increases associated to promotions, laterals, downgrades, etc. Don’t force the off-cycle process in the tool or it will turn ugly.
2. Ensure budgeting requirements are well understood early in the project between the compensation and project teams.  For example, what is the budget/organizational freeze date (or, is there a freeze date?), can budget funds be re-allocated during planning, what  do you do with terminated employees during the cycle, etc.
3. Don’t rely too much on “macro-eligibility” to drive your compensation eligibility rules. Infotype 0758 (Compensation Program) is where “macro-eligibility” is defined.  Putting too much intelligence in this infotype is a recipe for disaster because you are at the mercy of master data maintenance (PA30/PA40 transactions).  Bake your eligibility requirements into your “micro-eligibility” rules (including the eligibility BAdI) since you have absolute control over the logic.
4. Listen carefully to the requirements around compensation planning and approvals. For discretionary plans, ensure that the system is configured to handle the appropriate workflow and business logic to handle compensation worksheet level approvals, routing and escalation rules.
5. Ensure that all your process inputs (market data, performance ratings, potential ratings, etc.) are configured prior to the compensation worksheet being opened to management.
6. Agree with the compensation team on which master data will be entered by them in Production versus input by IT in Development (and transported to the upper environments).  Time-sensitive information such as Business Unit Results, Black Sholes/Fair Market Value, Bonus modifiers/kickers, etc. should be controlled by the business in the Productive environment.  This data may also be very confidential as well, for “comp’s eyes only”.
7. Give the compensation team the ability to proof the compensation worksheets before releasing to management.  Seems a given, but worth it’s own line.
8. Conduct your system testing with a dedicated QA system with unmasked employee/compensation data. (This may not be realistic for all companies due to budgetary and/or environment  constraints, I understand, but shoot for the stars and maybe you will reach the moon.)
9. Just because functionality is offered, doesn’t mean you should use it. Test the waters within a demo environment with the compensation team to ensure they really do want all the functionality offered. There is nothing wrong with hiding functionality until if (or when) it’s needed. For example, the Compensation Profile is neat but also can backfire on you if you expose too much data that’s difficult to explain (or – even worse – wrong!)
10. Don’t over-engineer the stock granting process.  At maximum, collect and split the stock recommendations, but all other activities (vesting management, exercising, life events, etc.) should be handled by your stock plan administrator.

Until next time!

Jeremy

@jeremymasters