Tempus Fugit!
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:
- breaks in time and insertions to correct history (while noting insertion date, i.e. distinguishing between the effective date and the actual date that a row or object was created);
- “fully” (within practical limits) automated retroactive and prospective processing, including complex event handling, to include the ripple effects of intermediate data and/or business rule changes;
- repositioning the data base and application logic to a specific date or elapsed time period;
- sufficient granularity of effective dating (which really means sufficient normalization of relational tables, sufficiently small Web services, etc.) to ensure that whatever dated changes occur are truly independent of all other changes;
- consistent effective dating across all platform components; and
- easily understood and consistently applied default dates to ease the customer and operational experience and to prevent errors.
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.
[…] given two posts on HRM Software. The Future of HRM Software: Naomi’s Preferred Behaviors and The Future of HRM Software: Effective Dating and just when my idling mind thought of this as a matchmaking software, it turns out to be the […]
2010-2015 effective-dating still elusive?
Effective-dating spans HRM and almost every deep ERP application. Example highly required by BioPharma: Production, inventory, and available-to-promise of super sensitive fertility drugs. Expiration dates depend on environmental factors that change coupled with effective-dating required for bills-of material (at multiple levels) decoupled with effective-dating required for FDA compliance support as well as plain audit on order-to-cash promises. We used to hard code this logic for MRP/ERP, but inflexibility greatly limits scale. Now I need to evolve this to full-stack headless JSON apps than act like documents with business logic that play well frugally in a multi-tenant database that is also distributed. Whoever can build this gets to $10 billion dollar run rate first.
There are some powerful examples of how to do this within the HR technology space, but most products don’t handle this well. If you’re not competing with them, you may want to speak with Stan Swete CTO at Workday.
Naomi, thanks for the pointer to Stan Swete CTO at Workday.
[…] given two posts on HRM Software. The Future of HRM Software: Naomi’s Preferred Behaviors and The Future of HRM Software: Effective Dating and just when my idling mind thought of this as a matchmaking software, it turns out to be the […]
Why future of HRM Software: Effective dating?
PeopleSoft HRMS has been using effective dating for many year already. I agree with Denise that PeopleSoft does the best job in effective dating. SAP seems to say that they can do effective dating in their HRM software. However, when I use ADP GV payroll which is based on SAP HR, and it is totally not a true effective dating system to me. SAP HR may try to do effective dating, but it organize data in a way more like a traditional application to me.
Vincent, There’s a lot more to effective-dating than tracking events and data changes. PeopleSoft, for example, isn’t effective-dated at the application level nor is PeopleCode effective-dated internally. If you want to have to dated sections of PeopleCode so that the right one is called depending on the effective-date of the transaction in hand, then you need to write more PeopleCode to get you to the right place. And I could say the same about SAP. It’s VERY difficult to effective-date systemically those older application architectures where the applications themselves are written in code rather than being effective-dated engines that are completely driven from effective-dated meta-data. If I didn’t make myself clear enough in my post, my apologies, but none of the products you mentioned are effective-dated at the applications level, systemically.
Naomi, I would like to add an additional consideration on effective-dating. Traditional HRMS systems use to track activities as in a single line of time. For example, one a employee joins an organization you keep track of all the events that happen for that single employee: his/her department, his/her position, his/her salary … If you draw a line representing the time, you will be able to set as dots all these events in the line.
However, life has changed and we are now living in networks: social networks (friends, professionals, …), teams (development, sales, …) , E2.0 tools(wikis, threads, …) , and so on. So, in this case, there is no line but a very fractal composition. It is a tree with branches, but the only difference is that there is no trunk, you always go back and find more branches.
I would expect in the coming years more software vendors developing effective-dating capabilities for this “network” approach.
Raul, This is a great point, and one to which I’ve not paid enough attention. Hopefully, there are a lot of folks at the HRM software vendors — at those vendors which are engaging fully social technology and social networks — who are working hard on the next generation of effective-dating, to include these more fractal-like requirements. Perhaps some of them will join this conversation to share their thoughts on how this might best be accomplished.
Great post as usual. On the customer side the historical data section is one to really pay attention to during a conversion. Many legacy systems today (as you document in your post) do a poor job of effective dating. As customers begin to convert these systems to modern HRM software they are unfortunately going to have to make some very hard decisions about bringing over historical data into the new system. The cost to scrub and map the historical data from the legacy system to the new system may be prohibitive for many customers. I hope that these modern HRM software vendors are designing into their applications a place to store, access and report on the historical data even if it is not converted directly into the main application tables or objects.
Michael, Thanks for adding your thoughts on this critical implementation planning issue. And it’s a big challenge. When converting from the mainframe generation of HRMS software, from the Integrals and the Tesseracts, to the early client server HRMSs, so the PeopleSofts and SAP R/3s, the historical data conversion challenges weren’t that great because the target systems didn’t remodel their data structures according to the strict considerations of (the then current technique)entity relationship data modeling. But this new generation of primarily SaaS HRMSs and SaaS talent management software, especially the best of them, have totally remodeled data structures, really object structures, which are quite a leap from their predecessors. Therefore, bringing historical data into these newer structures is going to take a lot of work. Where that effort isn’t warranted in terms of business benefits — and it may be so in some cases — we’ve got some work to do to decide how best to store, access and report on this historical data long after its originating HRMS has been taken off maintenance and out of operation. Perhaps some of our colleagues from those vendors with completely remodeled HRM software will share here the guidance that they are giving their prospects on this important topic.
[…] of creating a payroll application which could do much of this in an automated way. With a little effective dating here, and a little re-entrant code there, the first, modestly capable, retroactive processing […]
Naomi,
I think that you are definitely think that you have hit the nail on the head with effective dating. I have worked with a number of HR systems, with the first being PeopleSoft and the last being SAP and some smaller systems in the middle and I have been surprised at the randomness that some of the systems use with effective dating. I am sure that thought was put into what was and was not effective dating but it appears to have not been enough thought. I am particularly surprised with SAP (which I am fairly new to). For such a large and robust system, I am surprised with how many areas are not effective dated. Mainly it seems to be with their configurated items, such as Personnel Areas or Subareas, or Employee Groups. But when I took training the SAP trainer even mentioned that if these have to be changed, ever, that you should just update the name to reference that it is no longer used. But users could still technically use the value! However you can’t get rid of it because of the historic data.
I think that I am spoiled because I started out on PeopleSoft, which I feel does a better job with effective dating than the other software that I have worked with.
Thanks for your insight.
Denise, thank you for reinforcing the importance of proper effective-dating and providing some examples of where it’s not done very well. A lot of manual effort, errors and automated work-arounds — with all the attendant costs — are the price of poor effective-dating.
Hi Naomi. We’ve met several times by phone to review our strategy and products. I totally agree with your benchmarks for effective dating. After several years of development we successfully built an effective dated model layer in our architecture that provides all the benefits you mention, and more. We have been using it in with clients since late last year, and have seen tremendous value in benefits administration where events occur before or after they are known, and elections and other decisions result in changes that take effect at some other time. With pervasive model-based effective dating, we can easily process elections for the upcoming new plan year at the same time as we handle life events that took place last week and data changes that happened every day since then.
Here are some other things you should think about. In a fully effective dated model, when you go into the past, you have two dimensions of time: effective dating timeline (x) and transaction history (y). These provide very interesting possibilities when you can manipulate them independently. Tie them together correctly and you have perfect auditing as well as virtual “time travel.” Add a 3rd dimension and you can branch into pending worlds.
Tom Cooper, Chief Architect at Workscape
Tom, thanks so much for your terrific comments. And yes, I agree with the “extensions” you suggest, having worked with a number of clients in just this way. But, for my posts, I’m trying not to reveal too much of what goes on behind the mirror in the interests of giving those clients some runway. That said, there’s a lot more on this in my licensed IP, and I’m comforted to know that I’m on the right track. Heard your analyst day was well-attended; sorry I couldn’t fit in another trip up your way.