[Looking for an appropriate image to convey the necessity of deep integration across core HR (whose system’s name is HRMS) and talent management (whose system’s name is usually abbreviated TM), I remembered this really terrific graphic from Josh Bersin. Giving tremendous credit where it’s due, this graphic is from an equally terrific post by Josh entitled: “Workday 10: Talent Management And HRMS Converge and dated in March, 2010 (and doesn’t it seem almost quaint to be referencing Workday 10?). I won’t speak for Josh, but I’ve been preaching the need for tight integration across HRMS and TM ever since I released my first licensed HRM object model “starter kit” in 1995. That domain model makes very clear that any other approach is going to be full of fragile, costly to maintain and innovation-slowing interfaces. But of course no one was then delivering software that replicated my object model. Thus, I was very reassured in all of this by Josh’s perspective given that he was coming at some of the same questions from his own particular research.]
I’ve written previously about my strong commitment to precise and consistent definitions of terms used in our discussions of enterprise software and, especially, of HRM software. And once you’re committed to a precise and consistent definition of integration, it’s possible to determine which other business processes have sufficient numbers, depths and complexities of connections to core HRM to benefit mightily from having a deep integration with your core HRM software. Must payroll tax filing be deeply integrated (by my definition of integrated)? Valuable, but not essential. Background checking? Nope. Fixed asset accounting? Another nope. But basic financial and cost accounting? A definite yes.
So what about core talent management (TM)? What about those foundational processes of organizational and work design, workforce staffing and deployment, workforce development, compensation management, performance and succession, and all the rest of what we commonly refer to as talent management and which processes have long since been themselves integrated? Here I believe the answer is a resounding yes, and it’s pretty easy to see why. But please note that there are plenty of narrow (but important) talent management edge applications, particularly in the staffing area, whose connections across the rest of talent management are not sufficient to warrant their deep integration.
Every organization of any size has to have a core HRMS, a core system of record to manage its people-related transactions and organizational data, to be the source of the data needed to drive such HRM processes as learning and staffing and payroll and benefits administration as well as the many non-HRM processes which require basic data including who works here, how they are organized, what they are doing, and what they are costing us. The HRMS is where worker lifecycle events, from hire or contract with through layoff/fire/retire/end contract etc., are recognized, edited, recorded and reported.
Today’s HRMS must be capable of providing these processes for the entire workforce, so for every type and schedule of employee and of contracted worker. And as robots comprise an ever growing segment of the workforce, those robots which are not truly facilities and equipment but which perform their duties as part of a mixed human/humanoid robot team must also be recognized as a part of the workforce in the HRMS.
The earliest packaged HRMSs, dating from the early 70’s, were very basic and focused entirely on core HR recordkeeping and reporting. For many years, any automated talent management functionality remained custom-built before there too packaged applications appeared. Talent management applications and then more integrated suites gained their ascendency, in my opinion, because the last generation of core HRMSs, those on-premise, client server HRMSs which are now being replaced with (ideally) true SaaS alternatives, simply didn’t do the job of talent management (TM) very well. This left a lot of opportunity for innovation by smaller, more agile TM vendors and their new, often entirely SaaS products.
There are lots of reasons for the growth of standalone talent management applications and their aggregation and/or build-out into talent management suites, but a major reason in my view is that those on-premise HRMSs couldn’t keep up with the innovations in TM thinking and preferred deployment approaches for which leading firms weren’t willing to wait. Because of their much longer development cycles, and the pain of upgrading on-premise HRMSs (many to most of which were tied to on-premise ERPs, thus complicating upgrade projects), getting TM software from their on-premise HRMS vendor meant far slower delivery and adoption of innovation, something with which effective TM couldn’t live. And since that which is most strategic in HRM is perceived (but I might argue this differently) to lie much more in TM than in core HR, lines of business and HR leaders were quick to seize upon the availability of standalone TM applications and suites.
Without going into the whole history of how TM suites evolved from specific TM apps, with each vendor coming at the suite from their roots in a specific TM process (e.g. Cornerstone OnDemand from learning), the TM vendors and their products filled a huge need and grew their market rapidly. On-prem HRMS customers gladly layered TM apps then suites on top of their HRMSs, building and maintaining a shit load of interfaces to keep everything more or less in sync. But as true SaaS (or even cloudy) HRMSs have emerged, they have made TM a part of their DNA. And as on-prem HRMS is giving way to cloud HRMS with at least deeply interfaced but ideally truly integrated TM, I foresee the end of massive growth for the standalone TM suite market coming over the next year or two. And although I believe that the market dynamics are working against the overall growth rate of the TM apps and suite market, that doesn’t mean that the standalone TM product or suite market won’t be sufficiently large to support a few (fewer than there are now) successful TM suite vendors.
In my view, there is a tremendous need for deep and robust integration between the traditional HRMS processes, e.g. hiring a new worker into a specific position, and the related TM processes, e.g. ensuring that the new worker has attended the required developmental events, that their hiring bonus is budgeted for through compensation management and then paid via payroll, that their position has all the right attributes from its job evaluation and the right reporting relationships from it’s organizational design, and that their work schedule is optimized against the work schedules of their co-workers and the needs of their department/store/project team/etc. And without these applications being built organically, on top of a common architecture and object model, creating and maintaining the needed interfaces is both costly and fraught with constant, hard to manage change.
And the market would seem to agree. At the low end through mid-market in the US and Canada, ADP’s, Ceridian’s and Ultimate’s latest HRMSs include a lot of TM with more coming every day. At the high end of the market, Workday included TM conceptually from its start and has been building out its TM capabilities with considerable speed. And both Oracle and SAP tout the TM capabilities of their next generation “cloud” offerings (SAP via its acquisition of SFSF and Oracle via its development of Fusion and acquisition of Taleo) as central to the value proposition for their cloud HRMSs. Frankly, I can’t imagine an HRMS being built today for any but the very smallest organizations which wouldn’t include a healthy dose of talent management, of the functionality which had previously been the province of layered on TM applications and/or suites.
There will always be demand for great talent management applications and suites layered on top of the long tail of legacy on-premise HRMSs. And there also will be demand for add-ons in specific situations, e.g. in geographies which are underserved by comprehensive, integrated HRMS/TM offerings or in TM processes, like sales compensation, which cry out for very specialized applications with a huge depth of embedded intelligence. But I believe that the heyday for standalone talent management suites is over, that the rate of overall market growth has slowed (i.e. that the total addressable market is still growing but at a slower pace), and that there are now too many TM suite vendors chasing too few growth opportunities. A very few such suite vendors and their products, those with excellent, stable leadership, truly integrated suites and very good software will likely prevail and prosper, but many other TM vendors and products won’t. Some have already been absorbed by larger/broader vendors or been bought by private equity firms, and I believe there’s more of that in the future of the remaining TM suite vendors.
Hi Naomi,
You passionately make the point that “TM truly integrated with HRMS” is superior to Talent Only (that is layered on or somehow ‘post-integrated’ with HRMS). However you don’t spell out why exactly? (except for some good examples in the 3rd from last paragraph). I understand (& agree) that interfacing Talent Only on top of a pre-existing HRMS adds complexity, data inconsistency and cost. What I would value is more real world examples that explain WHY exactly to have HRMS & Talent truly integrated in a single system? Have you blogged elsewhere on this point?
Many thanks,
Donough
Fair question, so let me offer some additional sources of relevant use cases. In this post http://infullbloom.us/621/more-of-naomis-killer-scenarios-strategic-hrm-is-what-matters/, which is primarily about integrated talent management (what I had always called strategic HRM), you can see the underpinnings of position, job, work unit, and more core HR objects upon which talent management relies so heavily. In this post about worker life cycle scenarios http://infullbloom.us/659/more-of-naomis-killer-scenarios-worker-lifecycle-events/ you can also see many use cases where TM and core HR are interwoven. If you think these two earlier posts are helpful, I’ll update this post to include these older posts for reference.