I recently moderated a web forum with iProCon's Sven Ringling on managing and controlling the risks of local configuration and development in global HCM systems. Sven took questions on topics he’ll be covering at one of his upcoming HR 2012 session -- the feasibility of a centralized approach to configuration, defining controls for local development, the local changes typically requested by clients, and other topics.
For the full Q&A, you can view the questions and Sven's responses in the HR Forum, or read excerpts from the transcript of the Q&A below.
Amy Thistle (moderator): Welcome to today's Forum!
In today's HR Forum, we invite you to ask your questions about managing the risks of local changes in global HR projects. Today's exclusive, one-hour forum is with SAP HCM expert Sven Ringling of iProCon.
Sven is an HR Expert author and featured HR 2012 speaker, and he'll be presenting a session on this topic at HR 2012 Milan in just a few weeks.
Today, Sven will take questions on managing global HR projects, and avoiding the conflicts that can occur between local requirements and changes and global SAP ERP HCM settings and processes.
Sven, welcome, and thank you for joining us today! There are a number of questions already posted, so I'll let you jump right in!
Sven Ringling: Thanks for the intro, Amy. I'll note that our international topic can in theory touch every single piece of SAP HCM, so I won't be able to go into depth on each of them, but will do my very best. :-)
As everybody still seems to be getting their questions together, maybe let me throw in one point: the table I've seen messing up most in global HCM projects is T503 - if you don't take anything else from this session, always remember that MOLGA (country modifier) is NOT a key field of this table, even though some views suggest it. Not even the 'secret weapon' of line-oriented authorization I'll discuss in Milan helps much in T503.
Praveen G: Could you please elaborate on T503? Thanks.
Sven Ringling: T503 holds various groupings for employee groups/subgroups affecting payroll, time management, and other areas.
It is important to note that each combination of employee group and subgroup can be assigned to one, many, or all countries.
If it is assigned to more than one country, then ALL changes you make in T502 for that combination affect all countries it is assigned to now or will be assigned to in the future.
If you look at the table in SE11 or SE16 you see why: the country is a mere attribute, but not a key field in the table.
However, if you go into T503 via SM30/SM31 you will be asked to give a country - this makes people think that the changes they do affect that one country only. However, giving the country is just filtering away employee (sub)groups not relevant for that country - all remaining (sub)groups and the settings in the table can affect many countries.
That's why, in the SAP default (or sample) configuration, you see employee subgroups per country (D1, D2, ..., for Germany, U1, U2, ..., for USA) - this is safe, though not always very practical for very large organizations.
Pushhpa Maiwar: Hi,
We have implemented e-recruitment for one company in a Cloud environment and now we have to roll out the e-recruitment module for other locations like the US, UK, etc.
Please help me in knowing how we can handle the external candidate scenario for various countries differently, where an external candidate wants to register his job profile in the portal. For example, an external candidate from India has to provide his gender, marital status, and date of birth whereas contrary to this an external candidate from the US need not be asked to provide the gender, date of birth, etc.
How does the system understand that a candidate is from the US and a different portal screen needs to be prompted where the DOB and Gender fields are hidden (Maintain profile), or if a candidate is from India and the screen while maintaining the profile should prompt fields like Date Of Birth and Gender?
How can we handle this in a multitenancy environment?
Secondly, education types in e-recruitment get stored in one table for all countries. How can we filter these education types based on different countries in the frontend (portal) in a global rollout scenario?
Sven Ringling: Starting with your 2nd question:
Education types are by nature a global field, because candidates applying for a role in one country may have a degree from any country in the world. It is good practice to add a few more generic types where candidates with more 'exotic' degrees can find a choice that's close enough to what they've done -- otherwise it is almost impossible to cover them all.
(On a personal note: as someone from a country which hasn't used Master and Bachelor until recently, I found it very frustrating to apply in other countries, where companies didn't think about education types overseas candidates might bring.)
On your first question:
I'm not enough of a technical expert for e-recruitment to know all the configuration options in that solution. However, as you say, you work in a multi-tenancy cloud environment. This means, if you are using SAP, this is not the standard solution, which is by nature single tenancy, but you work on an artificial multi-tenancy basis provided by a third party (e.g., like Arinso's euHReka). Is that right? In that case you really need to discuss this with the respective provider as they all have their own bespoke restrictions of what's configurable and possible amendments to the standard solution.
Amy Thistle (moderator): Hi Sven - Could HCM global teams simply put a stop to local configuration or development? Is that even an option for most organizations?
Sven Ringling: Hi Amy,
In theory they could and I have seen this work. There is a strong trend to centralization, most notably in traditionally dominant cultures (like yours and mine, US and Germany, where there is also a strong base of SAP know how).
However, the more the global system develops into further modules and regions, the more difficult it becomes. Barriers are:
- time zones
- language
- special local knowledge not only in payroll
- being close to the customer and understanding their needs
- often high labor cost in HQ countries
The local knowledge and closeness to the customer are the most difficult ones in the long run. So in the end, there are very few organizations, where a 100% centralized approach works well.
Kir Chern: Hi Sven,
1. Is there any form of audit trail to log the changes to configuration or any means to log these?
2. There is more flexibility extended to end users to configure their UI and personalization. What is the recommendation of what to control, while at the same time open up some degree of flexibility for end users to personalize their UI look and feel? This is even more complex in a multi-country scenario, and also the complication when it comes to support.
3. Is there a template or a guide to refer to for defining the minimum control and procedure to have in place to govern development and configuration in a multi-country scenario?
Thanks and regards,
Kir Chern, Loh
Sven Ringling: Hi Kir,
Nice to 'see' you again :-)
1st question: Yes - changes to config tables can be logged. When you are in the configuration view, there is a point 'change logs' in the 'Utilities' menu. (Note: you must switch it on for the respective table - only after that is it logged. Many tables are switched on by default.)
There is also a switch for the whole system - ask your sys admin about that one
2nd question: This is a question of organizational maturity in using IT systems. Mature users, used to doing everything online at home, won't accept systems anymore where they can't personalize with favorites, etc. On the other hand, users not as IT-savvy may struggle with too many options and when they call the help desk, they struggle as well since every user's screen looks different. There is no 'law' for this, but my inclination would be to start with a more rigid regime and then open up over time and watch how users deal with it. There will certainly be countries where users demand and can handle more freedom earlier.
3rd question: I am not aware of such a guide freely available and detailed enough to be helpful. You'll certainly get templates when working with the big consultancies, but be aware that this need not necessarily match your organization's needs and in some cases looks like it's driven by the closeness to auditing arms. To be fair to the big ones, let me shoot at the small ones (like mine) as well: here you often find a lack of rigor in proposed procedures, as their own culture as small firms of knowledge workers is usually much more pragmatic than that of their clients.
At the end of the day, you need to find your way as an organization - potentially with some help. Solutions can vary from purely procedural to very technical like using the audit you mentioned and line-oriented authorizations - to advertise my Milan session again. ;-)
M.S. Hein: Hi, Sven. I have a question.
Which tables are especially affected by local changes, and what naming conventions and other best practices should we implement?
Sven Ringling: Difficult one as there are so many different scenarios. A strong overlap where global competes with local is in PA.
Think T588M - infotype screen settings. This is a typical one. Can create confusion, but easy to handle if you have clean conventions for the features involved to give a result for the variable key field with the country modifier (MOLGA).
Otherwise, apart from normal tables, it's features (often makes sense to have MOLGA as the first field to differentiate).
And even more dangerous than tables: function exits and BAdIs. Many affect all countries. Here I recommend to have an include for each country. At least that saves you from transport havoc.
Also T030 (payroll and expense posting). High risk in particular as the whole thing is transported every time, not just lines changed. Easier to get proper naming conventions in Payroll if you use feature PPMOD sensibly. But in expenses you don't have this, so you may need naming conventions in symbolic accounts.
In any case: when several projects are going on, do not transport without checking with others. It is easy for one group starting later, but going through QA faster and then getting stabbed from behind by the second group. Central control for T030 is advisable.
NancyChauvet: Hi Sven,
Could you give us a couple of examples of local configuration and development in global HCM systems that are typically requested by clients?
And your solution to eliminate (or at least reduce) the risk?
Thank you!
Nancy Chauvet
Sven Ringling: Hi Nancy,
Many examples in config are around reporting, when employee groups/subgroups, jobs/positions (not strictly config, but this makes it even more dangerous), Org Keys (field VDSK1), and further fields from IT0001 in particular are used to cover local reporting requirements. If global reporting is only developed over time after some rollouts, you easily find yourself running out of options and usage of criteria locally so criss-crossed that not even a proper mapping is feasible any more.
Therefore, I recommend defining in the global template which fields are local, which global, and where we may have a mix. Everything closely tied to payroll is better done locally. E.g.: if possible, stay away from employee subgroups in global reporting, but use org key or jobs.
The important thing is to get a definition done early - it won't be perfect, but leave you breathing space to build upon. Once 25 countries have used those fields at their own discretion, it is very hard to loosen the knot again (except for using AlexanderÄs method)
Sven Ringling: And maybe a final note from me: Wagetypes are often considered 100% local, because they are payroll.
However, requirements from global reporting as well as posting guidelines from group accounting are likely to come in. These should not determine your wagetypes, but you should make sure that your wagetype catalogue has the right granularity to provide an appropriate mapping afterwards. Extreme example: if local legislation allows you to use one wagetype for all gross salary elements, it may still be wise to distinguish a bit more as group reporting may ask for separate numbers on base salary, overtime, etc.
Amy Thistle (moderator): As I mentioned at the opening of the Forum, Sven will also be giving a number of presentations at HR 2012, including On-demand or on-premise? Figuring out which HCM deployment model is right for you and Best practices for managing local configuration and custom development in a global SAP ERP HCM system.
Sven, before we end today's Forum, could you also give a quick overview of other global HCM issues that you'll be talking about in Milan?
Sven Ringling: Of course.
Some may have figured out that line-oriented authorizations will feature prominently, but that's less than half of the session.
In a nutshell: In this session we'll start with a brief introduction of the global template concept. Then we'll look at the risk table-based configuration and other custom changes by local teams can create for other countries. At the heart of the session is the introduction and demo of the concept of line-dependent authorizations. We'll finish by looking at the limitations of this concept and how some of them can be mitigated.
And for what the session doesn't cover, I'll be part of ask the experts and can be bribed with a cup of tea to answer questions between sessions. :-)
Amy Thistle (moderator): Thanks to all who posted questions and followed the discussion!
A full summary of all the questions will be available here in the HR Forum. I encourage you to review our Forum posts and join the HR Group for ongoing information and additional resources.
I invite you to meet Sven in person at HR 2012 Milan, June 6-8. As I mentioned, Sven will be presenting a session on On-demand or on-premise? Figuring out which HCM deployment model is right for you as well as Best practices for managing local configuration and custom development in a global SAP ERP HCM system. For more details, simply visit the HR 2012 conference website.
And thank you again to Sven Ringling of iProCon for joining us today!
Sven Ringling: A big thank you for all who joined and contributed with their questions. Drop by, if you are in Milan! Or drop a line to sr@iprocon.com.
Amy Thistle (moderator): Thanks again, Sven, for the great advice and I'll see in you Milan soon!
