Matching Vendor/Product And Buyer Lifecycles

Vocabulary Shapes Our (Wishful) Thinking

This post was inspired by a Twitter exchange with a valued colleague after I tweeted that this might not be the best time to be a new buyer of Oracle PSFT/EBS HRMS given Oracle’s commitment to Fusion HCM as the next generation of these long-established product lines.  My colleague very correctly pointed out that Oracle is committed to supporting and maintaining PSFT and EBS HRMS via Apps Unlimited, but we disagreed over just what Apps Unlimited means.  In fact, Oracle has made very clear that there will be no EBS HRMS 13 and no PSFT HRMS 10 but that Fusion HCM will be their next major architectural generation.  But the real issue here isn’t the life cycle stage of any particular vendor’s products.  It’s  matching that life cycle stage to the needs of the buyers, and doing so such that there is completely informed consent before the buyer signs anything.

For buyers whose HRM needs are substantially administrative, heavily payroll-focused, not requiring much social-enablement or mobile support, needs which haven’t moved to self service as the only service and the list goes on, there may be no business case at all for migrating from the best of the last generation to the still embryonic next generation.  But for those customers whose HRM needs are aligned to driving business outcomes, whose workforce is expecting current and very mobile/social technology, whose administrative processes have long since been optimized such that the firm’s HR technology investments are focused on talent management and innovation of same, there may well be a solid business case for leaving that old friend software behind and moving on.  However, the worst of all possible situations is to think you’re moving on in 2011 to the best of the current generation of HRM software when what you’re moving to was designed in the mid-80’s, however renovated and updated since then. 

There are lots of resources to help you understand where a particular vendor’s products are in the life cycle from leap into the future to overtaken by one too many generations of HRM and technology changes.  The tougher question is where does and should your own end-user organization position itself in the life cycle from early adopter of new HRM technology to the latest of late adopters clinging to “old Sam” until the only person who can fix “old Sam” retires.  And just as every HRM product in your current portfolio is itself in a different position on the life cycle for products and vendors, so too are your different business needs positioned differently on the customer scale from early adoption to dying in place. 

Is your Tesseract payroll still doing yeoman service without undue cost or fear of failure?  Then put your scarce investment dollars elsewhere.  Do you have just twenty executives for whom you’re managing succession very nicely thank you on a spreadsheet with attached Word documents?  Perhaps this shouldn’t be your first priority for implementing that new talent management suite.  Happy as a clam with your PSFT HRMS, to include ALL of the associated support costs as well as the Apps Unlimited level of enhanced capabilities?  Then don’t be the first to “rip and replace” with either Fusion or the growing number of quite interesting alternatives. 

There’s no right answer here, no one size fits all.  But let’s not kid ourselves that buying last generation software in 2011 (as so designated by its own vendor and/or by the market), software that will take a year or two to implement, will take us to the future of HR technology.  All it will do is take us to the most recent past.  If that’s good enough, and the buyer really understands why it’s good enough, then who am I to say otherwise?  But I sure hope that all such buyers have “Followed The Yellow Brick Road” en route to this decision and considered what really happens to software once it’s well past its prime.

In the interests of full disclosure, I’ve been around long enough to have been there when we moved from custom-built then payroll plus software to that first generation of HRMS packages, and I’ve seen just how long old habits in automated HRM data design linger long after HRM business practices have moved on.  One of the biggest challenges with older HRM software — and even, unfortunately, some quite new HRM software — is the extent to which their designs date to a time when contingent workers weren’t considered an integral part of the workforce, workers weren’t entirely responsible for their own careers and financial futures not to mention entirely competent online, labor costs were an expense to be minimized through the management of interchangeable workers , and more.  With so much change in the nature of work and workers, not to mention the global economy and technology, it’s just not reasonable to expect to use a twenty-year-old set of such assumptions as the foundation for today’s strategic HRM requirements.  I should also mention that we would have done things differently in the 60’s through 80’s if we had been living with today’s HRM business needs and available technology, but we weren’t, and we didn’t.  Thus, it’s little wonder that you may occasionally have to “rip and replace,” no matter how painful, in order to keep up with the times and, more importantly, the business needs of your organization.