sbogner's blog

Year-end HRSP testing for US Payroll

SAP has released their year-end customer letter for US HR/Payroll customers letting them know which HRSP levels they need to be at by the en dof the year. The HRSP's will be released on October 15, 2009 - and then there's the mad rush to apply them, get them tested and patched-up, and then into production before theend of the year. Or, at least before the first payroll of 2009, and the first W-2 run for 2009.

As we find out more about year-end HRSP issues - and there are always issues with these updates - we'll post them here on the blog. Please feel free to add your experiences in the comments section, too.

Extend SAP 'features' with ABAP code

One of the powerful tools for configuring SAP HR is features – structured decision logic that looks at various attributes of an employee. Features are used to determine all sorts of things in the SAP HR system – which wagetype to use in paying an employee, which benefit plans they are eligible for, which pay frequency to use and so on.

Sometimes we need more flexibility in a given feature than the system provides. Maybe the decision logic has more steps than the feature can handle (i.e. the variable key is too small to support all the decisions we need to make), or maybe we need to make a decision on an attribute that doesn't exist in the feature. We can extend the flexibility of features by calling ABAP code, which in turn is used to make whatever decision we need.

Before I go into the details for constructing the ABAP code and linking it to the feature, I have to point out one very important restriction: The ABAP code only has access to the data that was passed into the feature. Every feature has a structure assigned to it, a collection of data items that is sent to the feature for it to use in its decision. In turn, the ABAP code only has that data to work with.

Here's a shell of ABAP code you can start with:

REPORT ZHR_FEATURE_CODE.

FORM ext_call_f USING namen back status struc STRUCTURE structure-name.

Is SAP's Concurrent Employment right for you?

SAP's Concurrent Employment (CE) functionality has been out for a few years now, and several customers have successfully implemented it. This CE functionality enables you to have multiple 'assignments' per person in the HR system. Think of an assignment as a job or position (not necessarily 'job' or 'position' in strict SAP-terms, but in a business-sense). If you have a sizable population of employees who work in multiple jobs or positions, then CE might be right for you.

In the traditional SAP HR model, an employee has one job or position at a time, keyed by a Personnel Number (i.e. 'pernr'). This works fine for most employers, but not those where a given employee may hold two or more jobs at the same time. For example, in a university a management staff person can also be a part-time faculty instructor. In a hospital, a doctor or nurse may work in multiple tax entities within the same corporation. Each of these cases requires the person to hold multiple positions, rates of pay, perhaps benefits plans, and other work-related information such as schedules and tax authorities.

Getting it right the first time

Installing a new HR system - like SAP HR - takes a lot of work; and it requires consultants with a lot of experience to install it well. That experience will help you design work processes that work well both with the system and for your business. Those processes and the technical configuration supporting them are the foundation for your system and all that you will do with it in the future - and that is why it is critical to get it 'as right as possible' early-on.

It's similar to building a house - you want the foundation poured well and in the right shape to support the house you will build on top of it. You want the right number of rooms for the purposes you need, with the walls and plumbing and electrical in all the right places. Once all that is built, it's difficult and expensive to change it - take a wall out here and build a new one there, and it's going to cost you. It's the same with SAP HR - once you get the initial system and processes built, it's going to cost you to change it.

And if you built a poor foundation - the wrong size or shape, with cracks in it - then fixing that after the house is built is major work. Or if you decide that the layout of the rooms just isn't working, it can be a major project to rebuild them the way you need. The same goes for your SAP HR system and the processes you've built up around it.

Benchmarking - Correlation is not Causality

I was reading some information from SAP and ASUG this week about their benchmarking results, and I was reminded of something my college Statistics professor drilled into us: correlation is not the same as causality. That concept is also mentioned in a very interesting book I'm (slowly) reading: 'Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management' by Jeffrey Pfeffer and Robert I. Sutton.

For example, one of the benchmarking results found that companies whose HR departments have more headcount devoted to HR-advising work vs transactional work have higher profit margins than those whose HR departments are focused more on transactional work. That might mean that if your HR department works on transactional efficiency to the point it can redeploy its resources towards more advisory sorts of work, that the company will earn higher profits. Or, it could mean that companies with higher profits have more to invest in projects that improve HR transactional efficiency. Do the benchmarking statistics tell us about which of those scenarios are true?

Syndicate content

Copyright © 2001-2010 by Insight Consulting Partners - Contact Information