The Problem With People

Earlier this year, I wrote a couple posts about the "problem with people" -- that is the problem of modeling people within HR processes and systems. Broadly speaking, the problem is that a single person associated with an employer or an employer-sponsored program has a certain set of intrinsic characteristics, but also has characteristics that are relevant only within the context of a particular role or relationship with another party.

The diagram below (click for large version) is intended as a high-level, conceptual depiction of some of these different roles.

As complex as the diagram is, it is easy to see how you might go much farther. For example, I've left out roles such as "learner." I also have left out detailed delineation among roles. For example, one that came to mind, but that I didn't depict in the diagram is distinguishing between the role of Candidate and that of Applicant. This can be a thorny issue since in many cases it might require application of "official constraints" (laws, regulations, etc.). If you've tracked what has gone on among various U.S. regulatory agencies (EEOC, OFCCP) in this regard, you know bright-line determinations are difficult (or should we just say "impossible"?). While this is complex, from a data modeling perspective it is possible to make simple assertions, such as that an Applicant is a type of Candidate that has become associated with an employment opportunity in manner consistent with employer practice, applicable law, etc.

Modeling People Across Roles

Why is this important? Consider that in the HR-XML 2.* architecture, each and every role depicted in the diagram above was within the library somewhere. However, each and every role was essentially a "one-off," modeled only for the purposes of the particular schema in which it appeared. As I've discussed in blog posts earlier this year on the HR-XML website and in presentations I've given this year, one of the important features of HR-XML 3.0 is its inclusion of a "meta-model" useful for organizing the different bits of people data in a consistent way across different roles. Perhaps after the version 3.0 candidate release is published (real soon now?), I'll revisit that meta-model in a blog post.

While I won't review the meta-model today, suffice it to say it represents a vast improvement over the design (or lack of design) within the 2.* architecture and is better than similar content within the libraries of peer standards organizations. One of HR-XML's founding board members, Gary O'Neal used to emphasize that success would depend on influencing others as well as opening ourselves up to be influenced. As I recounted in the recent series of posts, Looking Forward, Looking Back, HR-XML 3.0 represents the incorporation of best practices and design that originated outside of the Consortium. Knowing where HR-XML 3.0's person meta-model stands in comparison to similar work by peer standards organizations, I believe a next challenge/opportunity for the HR standards community is to perhaps itself to shift roles to being one of an influencer. The broader community of HR standards stakeholders benefits if data about employees and other HR person roles are represented more consistently in the standards developed by supply chain, insurance, learning, and other domains. HR has long shown it can effectively internalize business approaches, processes, and technology from the outside However, when the topic is people within employment and work roles, who other than the HR standards community should take the lead?