GOP View Of Obama's Health Care Reform Bill
This post is one in a series I’ve been writing about the preferred architectural behaviors for great HRM software, to include HRM SaaS InFullBloom (but many are equally important for single tenant HRM software regardless of how it’s licensed/subscribed and installed/hosted). I posted the introduction to this series in April, 2010, after I had already written some posts on the topic, and the whole list of previous posts on preferred behaviors can be found here.
HRM Has Zillions Of Business Rules
In HRM, there are zillions of business rules that must be applied properly to the relevant areas of HRM by process/business event, many to all of which have often complex variations by labor agreement/line of business/geography/etc. Then there are the process definitions that can and do vary by line of business/geography/local requirements/etc., business events whose data attributes/edit rules/processing vary by industry/geography/labor agreement/etc. and the list goes on. Every aspect of HRM policies, plans, practices, processes, data, etc. that are captured within HRM software may be applicable to an entire enterprise or just to meaningful subsets of that enterprise, where those subsets might be organizational/geographical/contractual/whimsical.
It’s important for great HRM software to be able to set up the relevant business rules/processes/data attribution/content/workflows/really everything just once — and maintained in one place — with an effective-dated expression of their applicability to the appropriate subsets of the organization and then be inherited by/applied to those subsets. In a multi-tenant SaaS environment, many of these business rules, especially the regulated and/or culturally common ones, may transcend tenants in their applicability and must therefore be inherited across as well as within tenants.
In modern HRM software, where most business rules/workflows/and similar are expressed as meta-data (which might be captured in and driven from a domain model) rather than as procedural logic, we’re “wrapping” chunks of meta-data (e.g. the description of a particular total compensation plan or the workflow of a performance process) with their applicability rules (e.g. this total compensation plan may be applied just to our business operations in Bulgaria and this is the workflow for the performance process used with all executive positions), also expressed as meta-data. And let’s not forget that all of this must be further “wrapped” with effective dates because not only do the business rules themselves change over time, but their applicability rules also change along with the inheritance of them. Are you ready to scream yet? Shall I go on?
Once that applicability is established, once you know that a particular business rule (which could be a complex as an entire total compensation plan or performance management process) etc. is applicable to one or more subsets of the organization (so to one or more work units, work locations, workers covered by a specific labor agreement, and so on), there must then be more specific rules (i.e. which are attributes of that total compensation plan and/or of the performance management process) for determining, within those subsets of the organization, which individual employees and/or non-employee workers (whom I call vendor employees in my HRM domain object model “starter kit” ) are eligible to participate/be covered by/etc.
For example, we may design a sales compensation type of total compensation plan that is only intended to be applicable to those work untis that are focused on the sale of our consumer products. But even within those work units, the eligibility criteria for participation in that total compensation plan might be defined by job, within job for just those positions that are based in the USA and, for the employees holding those positions, just for those whose tenure in the position is greater than or equal to 6 months. Even with their eligibility established for participation in the plan, they would still need to meet the accomplishment rules for an entitlement/payout under that total compensation plan, but that will be the subject of another post.
As another example, we might establish a performance appraisal process that’s to be used just for our IT-related jobs. And we all know that, where regulatory requirements dictate the business rules, reporting, processes, etc., that such requirements are applicable only within the geographic and “nature of work” juridiction of the relevant regulatory body. And just like applicability rules expressed as effective-dated chunks of meta-data (or via their object model expression), so too are elgibility rules expressed except when, as a result of their complexity, an eligibility calculation engine is used which is then driven by meta-data.
Determining an employee’s eligibility for participation in a specific, applicable total compensation plan (e.g., by their membership in a specific work unit and/or their working at a specific work location and/or by their performance of the duties and responsibilities of a specific job, etc.) is conceptually the same as determining and expressing the applicability of that total compensation plan (i.e. that it applies to everyone working in a specific work unit and/or at a specific work location and/or to people performing the duties and responsibilities of specific jobs). Therefore, the methods for establishing and executing eligibility and applicability rules should be as consistent as possible, easy to use, and be understandable to normal human beings, unlike the flowchart above.