Category Archives: ECM

ECM Nugget: “Lock Objects” in transaction PECM_PROCESS_SUPPORT

Budgeting, Compensation, ECM, SAP HCM, Talent Management, , ,

I wanted to share a useful piece of information about the use of the “Lock Objects” functionality in the program RHECM_PROCESS_SUPPORT_FOR_PLNG (transaction code PECM_PROCESS_SUPPORT) since it seems to come up in every ECM deployment that Worklogix is involved in.

Transaction PECM_PROCESS_SUPPORT for process support during ECM cycles
Transaction PECM_PROCESS_SUPPORT for process support during ECM cycles

First, there is a common misunderstanding that it’s about locking employee records. However, the “Lock Object” flag is only about locking Budgets (i.e., budget units)

Imagine you have an organizational structure having the depth of 4 hierarchical levels and the top node is A, subordinate from A is B, subordinate from B is C, and subordinate from C is D. Since Enhancement Pack 5 (EhP5), SAP ECM supports the employee-level budgeting approach (bottom-up).  This means we have 1) the budget structure as a mirrored org structure (BU-BU and BU-O) and 2) the employee budgets (BU-P).

Whenever a manager is logged into Manager Self-Service doing compensation planning, certain objects get locked. The system locks the employee itself (i.e. P and IT0759), the budget unit (BU) connected to the employee is locked (BU-P) and finally the budget unit (BU) connected to the org. units where the manager is the chief of is also locked. This leads to the dilemma that two functions of the Process Preparation Report (transaction PECM_PROCESS_SUPPORT) mitigate:

1) Option Update Planning and Budgets: Whenever an employee is turning eligible / ineligible, the employee budget is getting created or deleted. Therefore also the roll-ups are getting refreshed. This refresh doesn’t work when any manager is logged-into the Compensation Planning / Approval iView within the portal locking a budget connected to the org unit.

2) Option Recalculate Budget: Functionality doesn’t recalculate budget whenever any manager is logged into the Compensation Planning / Approval iView within the portal locking a budget connected to the org unit.

Dependent on how the compensation cycle is setup (is it a global or country compensation review; global organization or just within a region/country) the likelihood is high that there is at least one manager logged into Manager Self-Service during an ongoing compensation cycle. To bypass this dilemma, SAP has recently implemented the “Lock Object” flag. Whenever the flag is unchecked, the system is not checking any longer if a budget unit connected to an org unit is locked by a user or not. It always pushes changes into the database. Again, the “Lock Object” flag has nothing to do with locking an employee. It’s only about locking the budget structure by managers.

Here are the pros and cons of this functionality.

Pros:
As usually at least one manager is logged into MSS all the time, this facilitates the update of budgets significantly. Simply uncheck the flag and budget structures can be updated all the time. Additional programs which may kick out (or prevent) managers to perform budget updates are not needed any longer.

Cons:
The manager experience can be a bit tricky with these budgets, and proper communication should be made available to managers involved in the process. Let’s take an example where a manager who is logged into MSS and initially sees a budget of 100,000 USD. While the manager is logged in, you execute PECM_PROCESS_SUPPORT to perform a recalculate budget which reduces the budget in a lower org unit for example by 10,000 USD. This update is not immediately visible to the manager, but rather only when he/she opens another iView and then returns to Compensation Planning / Approval iView to get a refresh. This means that a manager who plans to keep his org unit budget at 100,000, but  in reality he only has 90,000, because someone executed PECM_PROCESS_SUPPORT in the meantime.

I would recommend to always use PECM_DISPLAY_BUDGETS to monitor any potential inconsistencies in the budget structures which can always be repaired using the button “Update Spent Amounts” in the budget audit report in case they exist.

Audit Report for Budgets

Hope this helps you. 

Top Ten Gotchas when Implementing SAP Enterprise Compensation Management (ECM)

Compensation, ECM, SAP HCM, Self Services, Talent Management, Variable Pay, ,

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