The Future Of HRM Software: Effective Dating

Did you think this was going to be a guide to finding the man/woman of your dreams?  Wrong!   

If you ask any HRM software vendor or BPO provider if their software is effective-dated, the universal response will be yes.  And they’re telling the truth.  Even the sorriest HRM software allows for the effective-dating of SOME data changes.  But when I ask if software is effective-dated, this post describes the standard against which I’m measuring not only the vendor/provider’s answers but also what I’m checking out via deep software dives.      

The Basics     

First, the basics.  I’m expecting to find systemic and easily used effective dating for all platform components, i.e. for each software object or Web service, for each “chunk” of data (e.g. row in a relational table or object with its methods and attributes in an object data base), or for each “chunk” of procedural code (although we really don’t want to see procedural code in the applications but rather confined to the application development tools that support models-driven development), which allows for:     

Every relevant row in a derived physical relational table or relevant object in an object data base should be described by effective date(s) where these dates (and the associated time of day) are based upon a global concept of date and time (i.e. Coordinated Universal Time, the successor to Greenwich Mean Time for this purpose).  When properly done, effective dating provides a natural audit trail, but the specific audit trail requirements by industry, contract and/or regulation may well (and do) impose additional design considerations.     

The Nuances     

With the basics covered, there are many more aspects to effective-dating that must be addressed:     

• Effective and correction dating consistency — even though some tables or objects could function without effective dating and/or correction dating (used to preserve the audit trail of changes), I prefer that vendors treat all tables or objects alike, i.e. with the same effective and correction dating attributes and behaviors.  This is much easier for the user to understand and use than having different patterns of effective dating for different platform components.  Rather than conserving computing resources, which was an earlier and necessary design principle, good design is now all about user productivity and effectiveness.
• Default dates — the software should presume that today’s date is the effective date/start date and that there is no end date for each action unless another date is given.  However, where this doesn’t make sense, e.g. where today’s date isn’t an appropriate elapsed time from another date (e.g. where hire date is before the approved budget date for the target POSITION*), the user should be prompted for a valid effective or start date.  Similarly, where open-ended doesn’t make sense for the end date, e.g. an open-ended assignment of a HUMAN RESOURCE to a project-type WORK UNIT of specific duration, the user should be prompted for the end date.  In all cases, there must be enough embedded intelligence to guide users to sensible effective dating decisions with clear explanations of the ripple effect of their choices.
• Prospective and retroactive processing — this is the ability of the entire set of HRMDS platform components to operate as of some future date (i.e. to model a future state, e.g. of an organizational change or a proposed TOTAL COMPENSATION PLAN design change) or, more commonly, calculate and account for/distribute the effects of a retroactive change with payroll impacts.  Retroactive payroll processing capabilities involve knowing what was, calculating what should have been, applying the right business rules to each delta, and addressing all of these changes in the current or future periods.
• Effective-dated event processing — the software should process retroactive, current and future-dated business events against the business rules (including all edits), embedded intelligence, and entity as well as reference data that are or were or will be applicable for the event’s effective date. Such event processing, if prospective, should also consider pending future-dated events that are waiting to take effect. 
• Forecasting and simulation — it should be possible for the HRM delivery system’s platform to forecast the impact if a particular action or group of actions were taken, e.g. what would we incur in overtime next month if we change work schedules as follows?  What would be our diversity profile if we make these workforce movements?  What would be our training backlog for the first line supervisor program (e.g. the backlog of eligible people for whom there are not yet any available training slots) if we have the following training schedule?  This ability to forecast should be both point in time (e.g. what would be our headcount as of year-end if we do the following…?) and period of time (e.g. what would be our sales revenues over the period x to y if we deploy ten more sales people with a mastery level of the following KSAOCs?). 
• Multiple chronological perspectives at one time — data and processes must be viewed from proposed, pending, current, historical and retroactive chronological perspectives.  Entity and reference data (or objects) must be synchronized with the relevant, effective-dated business rules.  Payroll processing is usually retrospective (if not retroactive), although it’s important to be able to run a payroll prospectively in order to forecast the impact of business rule changes.  New events must be viewed against current and pending entity and reference data (or objects).
• Historical data —  What event-based historical data is needed?  For how long?  At what cost?  How accessible must it be?  Who will decide? What happens when historical data is not compatible with today’s object model structures?  How do we “revise” history?  We must insert what should have been when it was detected (the date/time of processing) but with an effective date of when it should have happened.  Therefore, we must be able to distinguish among what we thought should have happened, what in reality did happen (although, perhaps, in error), and what has now been done to make the correct thing happen.  It’s impossible to even discuss these issues without 17 verb tenses.
•  Case management data — some business events are interrelated in very predictable, cause and effect, ways.  Where those events have a case-like resolution process, it can be quite useful to use finite state-processing to capture and process the many steps involved in the resolution.  Think environmental, health and safety incidents (a.k.a. EHS INCIDENTs), HRM GRIEVANCE/COMPLAINT, individual being taken through the evaluation process for a specific POSITION, and a TOTAL COMPENSATION PLAN claim.    

Using these notes to establish the baseline, it’s clear that every HRM software application is NOT fully effective-dated.  To check this out, some easily detected limitations include:     

• undated, presumed static attributes, e.g. gender;
• undated and either replaced or overlaid user-developed “code” in vendor-provided programming languages;
• security of access that’s attached to a person and for which there’s no ability for that person to process retrospective business events; and
• dare I say it, undated metadata and/or business rules.

Don’t take my word for this.  Check out your own packaged software.  And do give me your comments on who’s doing a great job on this — and who’s NOT. 

* When you see an HRM concept in all capital letters, this is a reference to one of the major object classes from my domain model “starter kit.”  With more vendors/providers using the “starter kit,” I thought I would begin using that formal terminology, where appropriate, to link the content of my posts to their work in modeling the domain for fun and profit.