cancel
Showing results for 
Search instead for 
Did you mean: 

Global HRIS vs Multiple Local HRIS instances : Which is better for Conglomorates?

Niladri_B_Nayak
Active Contributor
0 Kudos

Experts,

I have a scenario/usecase - Imagine a Global Organization is having 6Lakh+ employees head count with presence in 180+ countires globally. However, all 180+ countries this organization has their independent entity/company code.

There are free flow of resource augmentation happens across entities based on demand/supply of talent.

People from Entity 1 working for Entity 2, getting paid at Entity 1 for multiple years. They maintain multiple time sheets (depend upon how many entities they work for in a single day in 8 hours).

Each entity has combination of SAP SuccessFactors and 100+ local applications for handling People and Learning Operations

I would like to understand as Consultant/Business User,

  • How do other SAP clients (similar to above scenarios) handle their workforce data( Regular employees, contingent workers, employees from other entities ) in Multi entity structure in multi cloud environment ?
  • Do they use Single Global Instance/ Multiple Instance ?
  • What strategies they followed optimizing cost, quality, risk factors?

I want to learn really from your experiences and don’t want to reinvent the wheel . I have gone through series of ALP/IDP documents but they are not helpful.

Regards,

Niladri

View Entire Topic
nlgro023
Active Contributor
  • How do other SAP clients (similar to above scenarios) handle their workforce data( Regular employees, contingent workers, employees from other entities ) in Multi entity structure in multi cloud environment ?

    Firstly, set a global standard and only deviate locally if absolutely required. Ideally you leverage features such as cost distribution, global assignment and concurrent employment and think them through end-to-end (+ what the impact and necessary changes are on an integration level + make the needed adjustments) or you just make strict choices on why you don't use them and instead use other ways of registering them (which would then be stuff like consciously favoring 1 main account over the other and ensuring stuff is arranged more informally on a local level. That is pretty much the general answer as your question is quite general. You always have to align the specifics with all countries as for instance the US tends to be a special one in terms of taxation due to the states within the country, whereas other countries with provinces or states will not have the same complications.
  • Do they use Single Global Instance/ Multiple Instance ?

    Generally speaking they do yes, I've seen 100k employee, 300k employee and 500k employee organizations globalizing it. It makes it more difficult to get changes through, but from a cost, consistency, maintainability and reporting perspective it makes perfect sense. But there are of course always exceptions to the rule...
  • What strategies they followed optimizing cost, quality, risk factors?

    The 1 instance (I say 1 but I of course at least mean Prod, Test, Dev environment, ideally a 4th to get OTAP) already offers cost benefits as you can get license cost reductions. You just need a very strict change process, release management cycle, business continuity plan and good support organization (both global and local) to ensure nothing collapses when you change something in the system.
S0022299441
Explorer
0 Kudos

Great response by Jasper.

Perhaps, should the need arise, on the third question, if each of your entities comes up with its individual (or vertical) scoped enhancements or improvement projects, and this doesn't and shouldn't impact the other two entity data or model, then you may want to consider consuming (procuring) additional instances at preview and production release levels. That way, your PoC and Testing would be independent during the project before combining into one production tenant. Of course, after the project is live, you can use IRT to refresh your production to your regular test tenant.