HR Business Group Decision making process

AUGUST 21, 2012 LEAVE A COMMENT

One of the foremost client facing situations, we as consultants, have to deal with is the discussion around the design of the business groups. For
customers who are not previously on Oracle or those that are more accustomed to non Oracle ERPs this can become quite a daunting task of
grasping the concept, and then coming to a conclusion around its design. Further if they have a global presence and are looking for scalability this topic
can get quickly intricate. Clearly, they cannot do it by themselves and require expert guidance. They are looking for what everyone refers to as best
practice and more often than it becomes their key measure of gauging a systems integrators professional effectiveness. A sound recommendation that
is based on facts and industry experience is extremely important but what are more important are two other things the swiftness and
the approach while getting to the end-result. By swiftness, we mean how quickly can we provide them with either a recommendation or a framework
based on which a decision can be made; and by approach we mean how we lead them from beginning to the end. A prescriptive approach combined
with good supporting information can enable them to make their own decision. On the other hand a sluggish approach that suggests it depends kind
of an answer or lacks proper framework for decision making will clog their thinking, create confusion in their minds, and will make them look for
alternatives or at times even challenge your recommendation.
Provide a framework than just a best practice, and facilitate the decision making using the framework
Being in the industry for over a decade now, I have realized that if we condition a customer to the right way of thinking, the decision making process
becomes more productive and efficient too. So there are two things right upfront we should ask them to be aware of:
a.) A best practice is a guideline, and not a binding decision! In other words, after careful evaluation of the best practice, it is OK to not go with the best
practice if it does not suit their specific needs. On this topic there are more than one ways to design
b.) The old way of working is not always bad! As an analogy the sun has been rising from the east all these years and will continue to rise from the
east. And that isnt a bad deal at all. So suggest exercising caution while discarding old ways of thinking. Sometimes an old approach just needs a tune
up, and not a complete revamp.
The Framework
The framework that will be discussed below has been developed in the last couple years, and has been our standard when approaching the business
group discussion. I have personally seen customers appreciating this framework as it has given them all the necessary information, but more
importantly it has empowered them to take their own decision with their eyes and ears open. This framework promises to remove the guesswork, and
provides a customer with the hot buttons that facilitates their decision making. Once I discuss the framework in details I will show how to use this in
real life.
The framework is based on 12 considerations. Not all the considerations are equal in terms of their importance, but we have made sure we have
included all the parameters that one can think of as important while making the decision.
The big question is Is Oracle Payroll in scope? If the answer is yes then each legislation (i.e. country) should have its own business group!
If Oracle Payroll is not in scope, then here are some additional 12 parameters to consider:
1. Headcount by countries What is the headcount distribution by country where the customer has their businesses? In my experience most
customers who have a presence outside of North America usually have sales or manufacturing personnel. I have also seen that the headcount range
anywhere from 25 to 500 people and in some cases I have also seen more than 1000 employees. So weigh in on this factor earlier on. Does it make
business sense to have an HRIS person locally to manage the Oracle HR system for a smaller population? Also, keep in mind that anytime a new
business group is added, configurations have to be repeated in those new business groups.
2. Local Statutory Reporting From my experience this is another key factor to consider. This is because sometimes a customer wants the flexibility in
the future state to be able to run these reports from Oracle. A good approach here would be partner with your local HR Generalists and get some
questions answered like, a.) What kind of statutory reporting is required by different countries, b.) Which function is responsible for doing that HR or
Finance? c.) What is the cost associated with outsourcing these reports, d.) Are there any serious issues with the current process? A big pro of
business groups by each country is that Oracle offers a lot of out of the box statutory reports. This can cut down the cost of developing custom reports
to address these statutory requirements.
3. Impact on Purchasing A key factor to consider if an implementation has Purchasing in scope of the project. Purchasing Approval hierarchies work
only on two models a.) Position hierarchy and b.) Employee-Supervisor Hierarchy. If a customers requirements are such that they cannot be met fully
using the Employee-Supervisor hierarchy and they have to rely on Positions and Position hierarchy then going with Single business group is the best
choice. Reason being, Oracle does not support Position Hierarchies that can span business groups. Currently, there is an enhancement request open
around this issue.
4. National Identifier Another parameter to consider from an end-user perspective is how to deal with national identifier. Specifically, if the customer is
using Employee Self Service, and if that is the entry point of transactions. For single business group installations, the national identifier assumes the
format of the legislation that is connected to the business group. For instance, if the business group is United States, then the national identifier would
be Social Security Number. Now suppose in the same business group one has to fit a Canadian employee, an end-user wants to see Social Insurance
Number, and not SSN. Further the Canadian national identifier is an algorithm rather than just a formatted number like US SSN.

5. Local vs. International Address Styles Related to above, determining the address style is another key consideration. Generally customers who
have outsourced payroll to ADP or Ceridian and have Oracle HR as their front-end system would like to apply address validation as a part of employee
entry process. By enabling this validation it prevents incorrect combination of City, State, and Zip to pass down to payroll. With a single business group
this could pose a limitation if the intent is to house global employees. One way to get past this issue is to create a specific international responsibility
and update the Person Address DFF, and Location Address DFF to support the international style
6. Employee Tax Information Assuming that Payroll is out of scope, there is still the question of maintaining employees Tax information. An advantage
of using business groups by country is that country specific Tax Forms are available for entry and maintenance in Oracle. Should a customer want that
ability they can go ahead and use these forms, and then interface this information over to Payroll? On the other hand, in the absence of business
groups by country one has to make an decision on where to hold employee tax information.
7. Employee Bank Information Defining the business groups by country provides a customer with the predefined Bank Details Flexfield. These give
them the choice to store employees checking or saving account information in Oracle and interface it to Payroll for payments processing. Again if
Payroll is outsourced entry or maintenance of this information can be left outside of Oracle, but I have seen a couple instances where customers asked
for this information to be stored in Oracle just to make sure that Oracle becomes their reference point for all employee data.
8. Additional Information on Job Some countries like US and Canada allow capturing legislative information on Jobs such as FLSA information,
Overtime eligibility criteria etc. Though this is not offered across all the legislations, one can evaluate this if customer wants to take advantage of this
legislative support.
9. Extra Information Types Another key advantage of using business group by each country is that certain EITs are available out of the box. For
instance, Ethnic Origin for US, RFC Id for Mexico etc. As such this is not a big deal as one can create the EIT structures matching the different country
requirements under the same business group but every time we move away from the business group by country, this is an additional configuration that
one has to take into account.
10. HR Lookups The HR lookups are available in 3 access levels. User, Extensible, and System. What we have found out that the System defined
lookups and their values are driven by the legislation. For instance, a lookup called New Hire Reporting has seeded values Yes, No, Pending,
Incorrect. So this can be a pro for customers with multiple business groups because the legislative and statutory patches will always keep these lookups up to date. Conversely, if a customer has single business group, they will have to take into account the impact of maintaining such lookups for
countries outside their business group legislation. The other two types of lookups i.e. User, and Extensible come with a built in feature called as Tags.
Should you decide to use multiple business groups, one can enable tags as needed to support the local requirements. Note: It is important to find
out if the technical team/DBA has a plan to support you in the installation of legislative and statutory patches for multiple legislations.
Unless Oracle Payroll is installed for these legislations, this is considered as an overhead by the technical team and they push back in this
regard.
11. Default Job Posting Usually in iRecruitment there is a need to post jobs in local languages. There is really neither a pro or con of using single vs.
multiple business group but the implementation team has to take this into account and offer flexibility in the design of Jobs or Positions (as appropriate)
to meet this requirement.
12. Data Conversion Usually data conversion process remains the same regardless of the design of business groups. But should one decide to use
business groups by country or multiple business groups one has to incorporate all the seeded out of the box fields for the respective countries in the
data conversion mapping file. So make sure that you have cross checked with your business partners that they indeed need such additional fields. This
does impact the conversion code.

https://hcmtalk.wordpress.com/2012/08/21/hr-business-group-decision-makingprocess/