Global HR data is tough. Often times when we’re thinking about implementing a global core HR system, or a global data warehouse, we implement these systems according to a U.S. centric view of the world. (I’ll note here that I once worked with a U.K. based company that looked at their core HR system with an EMEA view of the world). This is rather disadvantageous since one of the ore problems with global implementations is that you usually start with skepticism and disengagement. This only increases when you propose your U.S. centric view of the world.
Translating not only data elements but any definition you are going to use is simply a starting point in translating data across global geographies, countries and business units. Before embarking on the implementation of systems, it’s truly useful to get some things straight. To do this, I’ll just give a couple of the more obvious examples.
— EEO (race) Codes: We love to report on EEO codes in the U.S. So much of our reporting is defined by these EEO categorizations, but we also know that EEO is exclusively a U.S. concept. As you travel globally, you quickly realize that race and ethnicity is not at all meaningful. If you go to Japan, they really could care less, since 99% of the population is actually Japanese, but they might care about ethnic variations in Japan. You might go to the Middle East where race and ethnicity does matter, but they also may want to know for discrimination purposes if you are Sunni or Shiite. In the end, most implementations I’ve done decide that trying to define and categorize race across the globe doesn’t actually make sense. Instead, they go after the thinks that they can collect like age and gender.
— Exempt versus non-exempt: Again, this is a U.S. centric concept that is defined by FLSA. If you went around the globe and talked about exempt employees, your audience would be bewildered. While it’s not a direct and perfect translation, most other organizations in the world can indeed relate to overtime eligible or not overtime eligible. Simply changing the data labels allows you to move forward with a global terminology that makes sense to everyone.
One of the key failure points of global implementations (there are many however) is the lack of common definitions across the globe. As soon as your global population feels that this is just another corporate initiative that U.S. stakeholders will benefit from, your international population will disengage. There are all sorts of prepatory activities you need to tackle prior to implementing, and data definitions is probably one of the first you should tackle.
3 responses to “Translating HR Data Elements globally”
You know I love this topic — down there in the weeds of interoperability and data interchange.
HR-XML 3.0 does a lot better than its predecessor in modeling these small, but thorny issues. Your examples above are great.
Here’s how we covered “FLSA status” – we actually generalized this to “WageHourLawCoverge”. See:
http://ns.hr-xml.org/schemas/org_hr-xml/3_0/Documentation/ComponentDoc/WageHourLawCoverageCode-element.php
http://ns.hr-xml.org/schemas/org_hr-xml/3_0/Documentation/ComponentDoc/WageHourCoverageEnumType-type.php
I do think just from a semantic analysis/data modeling perspective the EEOC/RaceCode issue is a bit crazier. After all, the US EEOC codes are quite an arbitrary set of enumerations some of which mix race and ethnicity. They only make sense in the specific context US EEO regulation. An insurance carrier recently pointed out to me that even in the U.S. there are a few states with insurance reporting requirements that specify their own race classification codes – So even if you model the concept of race in a generalized way, your model may need to allow for a way to classify someone under multiple official classification schemes. The HR-XML 3.0 way of handling this would be something like:
White (not Hispanic or Latino)
I say “we” above, since I was a principal force and architect in moving HR-XML 3.0 along — but I have moved on to other work. While I’m obviously upbeat about HR-XML 3.0, it has been released under a new license that is pretty ugly and if read litterally (which is sort the way licenses are meant to be read) makes it fairly unusable. I hope this simply represents a misstep that will be corrected.
Agreed. A great way to approach a global project is to start in Canada. The advantages are many:
* Shows a non-USA-centric perspective but doesn’t wander far from USA work management concepts
* Primary language is English but you have to deal with French — a good start for multi-lingual issues
* Geographically proximate to USA and culturally very similar — but still different
* Legislative differences – federally (no FLSA and different “EEO”; a federal Privacy law), provincially, etc – forces a detailed analysis while still using substantially similar terminology
* Quebec has Napoleonic code as basis of legal system
In essence, implementing first in Canada provides a small (10% size of USA) pilot that combines USA-style HR approach AND multi-lingual, muti-currency, with varied cultural opportunities.
[…] by Meg Bear on October 9, 2009 I was very impressed reading the discussion on SystematicHR about how a “Global perspective” is just that, a […]