Objects To The Left Of Us, Objects To The Right
I’ve been on the warpath about flawed HR technology object models (and their predecessors, flawed data models) for longer than most of you have been sentient. My pique on this subject goes way back to the late 80’s and a now infamous consulting gig at then PeopleSoft in its early days when I expressed my concerns about the flaws in their data model (some of which have surely been addressed, but whose core flaws ran really deep). I loved the technology leap that PeopleSoft made when they came to market in the late 80’s, and I loved the vision Row Henson, then their HRM product strategist, had for HRM and her HRMS products, but I deplored the fact that they had not produced a contemporary data model of HRM as the basis for their then next generation software. Fortunately, Dave Duffield and his leadership team didn’t hold my data model dinging against me, except perhaps for their sales leader.
Over the following decades, I wrote and spoke publicly about this subject often enough that folks were beginning to get bored with my preaching (did you think I hadn’t noticed?). But all of the HR technology built throughout the 80’s and 90’s, and even much of what came to market early in the new century, continued to be built upon flawed model foundations (and some vendors still weren’t using formal models in their designs, if you can even believe that). But instead of just wringing my hands, I began licensing my HRM Object Model “Starter Kit” across the vendor community from the mid-90’s, along with the recommended architectural behaviors, in hopes that would make a dent in improving HR technology underpinnings — and it did.
Then, in response to many requests, iIn May 2012, I published a blog post that covered the basics of objects and object modeling — the very basic basics. Assuming you’ve all been studying this topic since then (if you hadn’t already done so), it seems like a good time to note that simply applying the right modeling techniques does not get you to correct and complete HRM object models. Au contraire. I’ve watched many, very smart HRM enterprise software architecture and modeling teams do their best, but it’s a rare team that doesn’t make one or more of the same errors, and they’re doozies. And while I’ve covered all of these potential errors in my HRM Object Model “Starter Kit,” which is great for licensees (please note that I no longer license this material) but not so great for everyone else, I decided to highlight the most challenging ones through a series of blog posts for the benefit of those vendors — and their customers — who didn’t license my “Starter Kit” (and even for those who have a license but may not have modeled correctly these specific challenges).
I should also add that, if a vendor’s applications are created/maintained via a robust, models-driven, metadata-based, effective-dated, definitional development environment, etc., it’s a lot easier to adjust the models and resulting applications over time than in a traditional, procedural logic approach to applications development — and this agility really matters. Throw in a “Blooming SaaS” architecture and fundamentally great functionality, and you’re really cookin’. Since it’s so important that the object model be fundamentally correct and complete (for the desired scope of functionality) in any software you may choose to use, and the only way to get at this as a prospect/customer, short of reviewing object diagrams (which are impenetrable for all but the fully initiated), is to use case-based (aka scenario-based) product evaluation, that’s clearly the only way to go.
My first post in this series focused on the difference between job and position, and I urge you to read that before proceeding.
Separating Position From Worker
Work and workers are two fundamentally different concepts, and getting them right, along with their appropriate attributes and methods as well as relationships, goes to the heart of having an effective enterprise HRM application. For example:
- We interview position seekers for one or more specific positions (whether empty or filled but expecting to be emptied).
- We design employee career paths as a series of positions to be held.
- We develop succession plans for specific positions to include named employee, contingent worker, or position seeker (in this case a person who may not be known otherwise to the organization but who is created by the organization as a position seeker during succession planning).
- We hire, transfer, and promote employees into positions.
- We terminate and retire employees from positions.
- We contract for contingent workers and assign them to specific positions.
- An employee or contingent worker may do the work of one or more positions at the same time, or a single position’s work may be done by one or more employees or contingent workers.
- An employee or contingent worker may self-identify as a position seeker by applying for a specific position.
No one should be using an HRMS, let alone any talent management applications (and you know I feel strongly that these really deserve full integration as HRMS/TM, unless there are distinctly different and quite separate objects to describe:
- The nature of the work to be done and how it’s organized into positions defined by jobs;
- Those roles in the person object class structure (so those types of persons) which have done, are doing and/or could do work for the organization via their explicit, transaction-created relationship to one or more positions as employee, contingent worker, and/or position seeker; and
- How specific workers are related to specific positions, e.g. a worker may be the named successor for a position that’s occupied currently even as that same position is associated with one or more employees via their career plans, or the usual work schedule for this position (which is associated directly with that position) may be 9:00 AM to 5:00 PM daily but, when filled by Naomi, the actual work schedule will be a negotiated 10:00 AM to 4:00 PM because of her incredible productivity and associated with the relationship between Naomi and that position.
As a side note, I’ve been updating my HRM object model thinking to allow for the mix of human and humanoid robot workers, but that’s a topic for another day. Let’s stick with the basics here, focusing on human workers.
Within the person object class hierarchy, there are person objects which have nothing to do with the work of the organization, e.g. shareholder, person designee (someone designated by an employee who is participating in a total compensation plan for which having a designated recipient of provided benefits is a part of that plan’s design), or customer. But there are other person roles through which the work of the organization gets done:
- The obvious employee role (both current or past as defined according to the appropriate geopolitical jurisdiction having that responsibility, e.g. in the US, who is or is not an employee is defined by the IRS);
- The vendor employee role (an individual who does the direct work of the organization, not through an outsourcing of process or the purchase of results/products but rather through the carrying out of tasks within the organization itself and who is not an employee but rather a contractor of some flavor, again according to the appropriate geopolitical jurisdiction having that responsibility e.g. in the US, who is or is not an employee is defined by the IRS); and
- The position seeker role, which could be an employee or contingent worker who has self-identified to fill a specific position (or expressed a broader interest in working in a job, work until or work location of the organization), or has been designated as a named successor via a succession plan for a specific position, or someone of whom we’ve never heard before who either has self-identified as or been designated as a position seeker (where this is usually subject to the organization’s own business rules).
[Please note that a single physical person can of course fill one to many of these person roles either serially or concurrently, position seekers may be applying for work generally with the organization, at a particular work location, for any position defined by a particular job, and these are just a few of MANY more complications that I’ve left out to keep this post from eating all of Florida.]
As noted in my first post in this series, jobs are templates from which positions are created. Jobs describe broadly the nature of the work being done, in terms of what I call duties and responsibilities, as well as the KSAOCs (knowledge, skill, ability and other deployment-related characteristics, so these include surrogates like work experience and education, attitudes and behaviors, work schedule and environment preferences, etc.) and level of mastery thereof that are needed to do that work.
But work gets done via workers “sitting” in positions and carrying out the duties and responsibilities of those positions. Positions, once created from a job template, must be given a work location (which could well be telecommuting), a negotiated work schedule (if different from the usual one), and their association with (place in) one or more work units. Although they inherit a lot of their attributes and methods from job, positions may be assigned more specific duties and responsibilities, more specific KSAOCs and/or the weight and rating accorded to those KSAOCs. Positions may also be given the rules by which accounting for the costs associated with those positions will be done (i.e. when cost accounting isn’t done on a time and attendance basis), rules for any position controls (whether headcount or budgetary) that will be applied when filling those positions, and rules for establishing the fit/recruiting sources/evaluation process/etc. when filling these positions should they need filling (i.e. succession plans, sourcing rules, etc.).
So what’s the big deal here? Keeping position attributes and methods (nature of the work, desired profile of the worker, budget for the work, duration of the position, planned work schedule, and more) quite separate from the characteristics of the worker (preferred work schedule, agreed term of employment, negotiated hiring bonus, agreed accommodation in view of a disability but regardless of position, etc.) seems like a no brainer, but I assure you that many legacy on-premise systems still in use don’t do this very well or completely. And, even when the software can do this right, implementations carry forward lousy coding structures that go back decades to a time before we had great object models. And if you think it’s a muddle now, just wait until you’re generating predictive, embedded analytics at in-memory speed to inform managerial decisions on the basis of truly muddled data stored in outdated and/or just plain wrong data or object structures. Yikes!
So that I don’t violate every principle Bill Kutik has tried to teach me about reader attention spans, I’ve just done the separating position from worker thingy here. But please stay tuned as I work through a whole list of persistent object model errors — and let’s not even consider any vendor who’s still working with purely data models because they’re so far out of date in the art and science of software engineering that they’re probably wearing tie-dies and bell-bottoms around the office when such garb is really only appropriate for attending aging rocker or folky concerts.
- Job and Position
- Separating Position From Worker
- Employee Status Code
- Decomposing Total Compensation Plan Into Reuseable “Legos”
- Addressing Multiple, Concurrent Worker To Position Relationships
- Balancing Total Compensation Plan With Work Environment ProgramCrafting The KSAOC UmbrellaCommunity MembersProfessional Network and Networking As KSAOCsSeparating Work Unit From Work LocationSeparating Work Unit From Legal Entity
If I get that far, and you’re still interested, I’ll keep writing on this topic. Meanwhile, if you’re a customer, starting checking your current portfolio of HRM software for the proper separation and implementation of job and position. Lots more relevant use cases for work and worker can be found here here here and here.
Different But Equally Beautiful
[This post was inspired by an exchange in the HR Technology Conference discussion group.]
When I look across all of HRM with the most expansive and contemporary perspective on work and workers (so here I include humanoid robots as workers but clearly not persons), I see the need and market for three very different types of applications. I’ve chosen to call these (making it very obvious that I am NOT a marketing guru) utility, core and niche applications.
Utilities are those cross process foundations which are critical to providing customers with a terrific user experience while enabling all of the goodness needed by vendors in time, quality and cost-to-market and, in the world of Blooming SaaS, operational efficiency and effectiveness. Increasingly, the term “platform” is being used to refer to the collection of these utilities, to the foundations upon which subject matter/domain applications are built, and I’m okay with that. Included, therefore, in the platform are such capabilities as UX design, workflow, process management, inheritance across and within tenants, metadata management, systemic effective-dating, collaboration, video creation and embedding, mobility and the special considerations of mobile security, overall data privacy and security, reporting, analytics, and much, much more. What’s important is that most of these utilities are very difficult to piece together by an end-user from disparate vendor products (although some of this could be done, with considerable pain and cost, both initially and in perpetuity, on a best of breed basis). These utilities deserve to be part of the foundation of your HR technology strategy and are best obtained from the vendor you choose to provide your core applications.
Core applications, back in the day, referred to basic HR recordkeeping, payroll and benefits administration with some basic T&A thrown in. But today this core must include a broad range of workforce and talent management applications, from staffing and compensation management to development and succession and on to basic scheduling, assignments and time recording. Today’s core is MUCH larger than that of yesteryear because we’re automated so much of what used to be done either manually or via an array of spreadsheets and similar office tools. I define core as those applications which have deep and complex interconnections across and impact on work locations, work units, jobs, positions, persons and person roles plus non-person workers, and every flavor of knowledge, skills, abilities and deployment-related characteristics (what I call KSAOCs). This core is the foundation of your HR technology portfolio. It sits on top of the utilities and is enabled by them, and much of it is absolutely required for organizations of any significant size. I think it’s critical to get as much as possible of the core from a single vendor but only if that vendor can offer you a truly integrated core. And of course today’s core includes a deep reservoir of truly integrated embedded analytics, both operational and predictive.
And then there are the zillions of important niche applications which live around the edges of that core. From background checking and social sourcing to tax filing and assessments of all kinds, there’s a lot of valuable innovation going on in these many niches, but their interconnections to the core are well-defined and not terribly complex. No matter how cleverly done is sourcing sourcing, it doesn’t change independently the organization’s design of positions. And no matter how important tax filing may be, the data required to drive it is pretty stable and straightforward. Sometimes, what starts out as a niche application, as did many ATSs, evolves to become a critical part of the core as the scope and complexity expand along with its interconnections across the core. Others begin and remain niche applications, like tax filing or background checking, because their interconnections to the core begin and remain well-defined and quite bounded. But in the end, what characterizes a niche has nothing to do with it’s importance, degree of innovation, addressable market or the flow of VC funding but rather the ability to bound its interconnections with the core in such a way as to enable relatively easy and survivable interfaces.
My view is that you should get most of those utilities, i.e. the platform, and as much as possible of the core applications from a single vendor (even if that vendor isn’t the owner of all the platform components) and then interface via APIs or platform-built extensions as many niche applications as are needed by your specific organization. We will always need to be able to do these types of interfaces, and I hope that we get much better at doing this, but trying to piece together the core as a long term proposition is not the preferred approach, at least in my opinion. And let me say it one more time: just because it comes from a single vendor does not mean that it meets my definition of integrated nor that it’s good software. So much for my point of view on this topic; what’s yours?
The Bloom Girls And Husbands In Israel
[It’s been three months since I did my last direct client consulting, and I’m loving the transition to industry observer and kibitzer. I’ve got two major blog post series underway — one on persistent errors I see in the underlying object models of far too much HCM software (including brand new software) and one a series of rants about the sloppy (and sometimes deliberate) misuse of important terminology — and lots more to come. But first I’d like to finish this post that’s been waiting a year for me to digest and process all that we saw/heard/smelled/learned on our first (and for me life-changing) trip to Israel and Jordan in the Spring of 2014. Now this may be of no interest to you, and I will get back to business shortly, but first I want to share with anyone who’s interested what happened to me on this trip and why it was life-changing. My hope is that this post, most of which was written before last year’s Israeli/Hamas conflict erupted and without reference to it, will give readers a very personal backdrop to that conflict.]
It has taken me a long time to process all that we saw, smelled, heard, touched, tasted, etc., during our recent, first trip to Israel. It was a life-changing trip for me, and I don’t say that lightly. All travel is adventure travel, and Ron and I have done more foreign travel than most, but for me Israel wasn’t foreign — it was home. And that was just the first surprise.
Until this trip, I never appreciated what Benyamin Netanyahu meant by the term “existential threat,” but even I could follow the clues that this trip provided. The first clue was the very odd route you fly from Istanbul to Tel Aviv. You stay way offshore until, at the last moment, you make a quick turn and an even quicker descent into Tel Aviv’s Ben Gurion Airport. The reason for that otherwise strange-looking route becomes obvious when you study the flight map: there are so many dangers along the more direct route, so many countries and/or militias which loath Israel, and so many terrorists with shoulder-fired rocket launchers who would love to take down a plane headed to Israel.
The second clue requires a more careful look at the map of Israel’s neighborhood and how that map has changed over the course of Jewish history. Studying that history, the reality of Israel’s small size and tough neighborhood hits home as does the fact that most every successive ruler of that part of the world has tried their hand at wiping out the Jewish people — not to mention the efforts of most every ruler of most every country into which the Jewish Diaspora took refuge. If everyone really is trying to get you, it’s not being paranoid to say so, and this is the truth of Jewish history.
The third clue was found in our visit to Independence Hall, formerly the art museum of Tel Aviv, which was the site from which Israel declared its independence to the world on May 14th, 1948. In a very modest white-washed former gallery whose art works are still hung where they were, with a simple table for the declarers and an even simpler setup for the provisional members of the provisional Knesset, we sat where the dignitaries then sat, we listened to that declaration, and we wept. Tears of joy for sure, but also tears of sorrow, because we knew that the joy of that announcement in 1948 was followed by the combined efforts of Israel’s neighbors to wipe our homeland off the face of the earth, to finish the job that Hitler could not. The young man who did the presentation could have been my grandchild, and he certainly didn’t hear about any of this first hand, but like every other young adult, he had served his time in the military and knew that there were still many of Israel’s neighbors who continued to hope, plan and work towards her destruction. At Independence Hall in Tel Aviv, in the very room where the State of Israel was born, you can feel that threat and the strength of Israeli to meet it.
The fourth clue, and the most powerful impression from our first day in Israel, came after we finished touring — Museum of the Diaspora, Itzhak Rabin Museum (which really covers the history of the Jewish State), and our visit to Independence Hall. We were sitting in a cafe having some wine and discussing the events of the day when a group of Israeli soldiers, men and women, came in laughing and sat down next to us with their automatic weapons in hand. Those young people, full of exuberance and the chatter of youth, were living life fully, even with an understanding that their country was facing an “existential threat,” that is a realistic threat from very capable enemies who are truly committed to their destruction.
Watching these young soldiers, three thoughts went through my head. The first was that we need to buy more Israel bonds, and we’ve done that. The second and more profound thought was that these soldiers are not only defending Israel’s very existence but also mine and that of Jews everywhere. But the third thought, which really surprised me, is that I am a Zionist, that I not only support Israel as the Jewish State but that I believe absolutely in our historical connection and rights to these lands.
From A Minority Living On Sufferance To A Majority Living Life Fully
On our second day in Tel Aviv, we had the most amazing experience ever at a museum when we visited the Palmach Museum. Here, instead of viewing exhibits, we were inside of them. The whole history of Israel’s fight for independence came alive through the stories of one Palmach unit, from their initial recruitment, through long years of training, to their being battled-tested, burying their dead and becoming a part of the new State of Israel’s IDF (Israeli Defense Forces). I didn’t think I could walk so far (many of you know that I have mobility challenges), but there was no way I wasn’t going to push myself to the limit, no matter the pain, as we became part of these young people’s pushing themselves to the limit in defense of their country. We emerged totally drained but understanding a lot more about the price paid for this amazing country, the price paid so that Jews won’t live — and die — at the mercy of whoever happens to run the countries in which we live.
For the Jewish people, who have been a minority across the Diaspora, living quite literally on sufferance from whoever happened to be in power at the moment, there is nothing sweeter than knowing that here, in Israel, we are the majority. Even with a sizable Jewish population in my American home town of the late 40’s/early 50’s, we were still taught to keep our heads down, not to call attention to ourselves, not to give our gentile neighbors any reason to think ill of us. So it was truly life-changing for me to be in a country where most people look like me (not the senior I’ve become but the young woman I was), where their sense of humor is the same as mine, and where their confidence and, yes, pushiness is a virtue and not something to be guarded against. No Jew lives in Israel on sufferance — under an existential threat, but not on sufferance. And again, as we rested after our tour of the Palmach Museum, I couldn’t help thinking about Zionism and what it mean to be a Zionist.
Borderlands: The Golan
If you use Google Earth to look for Metula, in The Golan, you can’t help but see the difference in the landscape on the Israeli versus Lebanese or Syrian sides of the borders. What you won’t see are the signs all along the roads on the Israeli side of the Syrian border warning you not to walk off the roads because of the zillions of land mines that Syria planted when they held that territory. You also won’t see — but we did because our guide knew where to look — the fortifications that the Syrians had been building on their side of the border whose only purpose could be offensive. Just days after we were there, the Syrian civil war pressed right up against the border with Israel, and tourists were discouraged from visiting this area for fear that the Syrian conflict could spill over. But we were able to see with our own eyes that there is so little protection for Israel from the next war her neighbors decide to start.
However, the most important learning from our trip to the Borderlands (my term), and our stay at Kibbutz Kfar Blum, had nothing to do with borders. When I was 11, being raised in an Orthodox Jewish home, and a very good Hebrew School student, I learned along with the other girls in my class that what was until then a completely integrated program with the boys our age would now become a split program. The boys would be prepared for their Bar Mitzvahs, and the girls would be prepared to run a Jewish home (think mid-50’s). This didn’t sit well with me (perhaps I was born with feminist sensibilities), and thus began my exodus from orthodox Judaism — but not from the values and cultural foundations of my childhood. And those foundations run very deep, not unlike the foundations of Jewish history in Israel. With each passing day in Israel, I found myself more connected to my own Jewishness and more aware of what that means to me now.
At Kfar Blum on our first morning there, on that Saturday Shabbat morning, I sat in the garden below the in-house schul, through whose open windows the sounds of male davining took me back to my childhood. There’s something about this place which awakened in me a sense of belonging, of being a part of something that goes back thousands of years and has resisted so many efforts to destroy it. When I look at the history of this part of the world, I understand now why using the term “Palestinians” to suggest that they are the authentic inheritors of this land has always made me crazy. Jews have been here from the beginning of recorded history as the archeological evidence makes clear, and it’s time everyone got used to the idea that this is our land, our place of birth. And we’re not leaving! So perhaps I’ve been a Zionist all along and just didn’t realize it?
Jerusalem of Gold
On May 4th, 2014, the sirens sounded in Jerusalem at 8:00 PM local time. In our hotel room at the David Citadel, we turned on the TV to see if we could figure out what was happening, and there was a service starting at the Wailing Wall to mark the start of Israeli Memorial Day. Watching that service, I couldn’t understand much of the Hebrew, but I knew what they were saying. In such a small country, where most everyone serves in the defense forces (IDF), every life lost defending Israel against three major attacks by her neighbors (1948 War of Independence, 1967 War and the Yom Kippur War in 1973), not to mention all the other skirmishes and Gazan wars, is a friend or family member, a classmate or bunkmate, a neighbor or fellow Yeshiva bocher. Israelis are all mishpocha, all family. I joined in when they recited the memorial prayer and again when they sang Hatikva, and it suddenly hit me that I too am mishpocha, that we are all mishpocha. And those brave men and women who were being memorialized died not just to create and preserve Israel but for the safety and future of the Jewish people.
On Memorial Day, May 5th, we began our day at The Western Wall, a place awash in its own history, surrounded by even more history, and arguably the most sacred place in the world for Jews of every flavor. To be there on Memorial Day was very special. Very early in the morning, we made our way there, my sister Marsha Bloom Weitz and I to the women’s section (yes, for once in my life I didn’t make a scene about this segregation by gender against which I railed loudly as a young orthodox woman), and my husband Ron Wallace and brother-in-law Irwin Weitz to the men’s section. Walking down the sloped plaza, performing the ritual hand-washing, then approaching the wall itself, I could feel the power of this place where so many have prayed for over three millennium, ever since the time of the First Temple. We said yahrzeit for those we’ve lost, special prayers for friends and family who were facing great health challenges and a general prayer for the good health of all we love (Marsha and I, by long tradition, pray only for good health), and then we said the special memorial prayer for those who have fallen in defense of Israel. I was fortunate to have two mothers, and I remembered both of them in Jerusalem: Sarah, my birth mother, died when I was too young to know her, and Bertha, who raised me as her own. Saying yahrzeit for both of them at the Wailing Wall, I knew that they were listening. After a long quiet period of prayer, we placed our prayer lists in a crack in these ancient stones, as is the custom. We stayed there, sitting quietly in the provided chairs, just absorbing the atmosphere. Tourists, ultra-orthodox women with their very conservative dress, and a young female soldier, automatic weapon slung over her shoulder, all praying together as though they had been neighbors for years. Mishpocha in our sorrow and in our triumphs, and reminded by the Western Wall and all that surrounds it of our many millenium claim to this land.
Is There A Path To Peace?
And just as I’ve relearned the history of the Jewish people, relearned my own history, I’ve seen firsthand why peace may not come in my lifetime. How do you make peace with someone who is determined to drive you into oblivion? How do you make peace with someone who raises their child to be a suicide bomber? How do you make peace with someone who hates you as much as many of Israel’s neighbors hate them? When you see in person the hard won agricultural miracle that is The Golan (you only need to see the awful, rocky landscape to understand with what effort and sacrifice the Israelis have created their farms), and you see a moonscape just feet away on the other side of the border, there’s living proof that Israel’s neighbors — and their wealthy co-religionists across the Arab world — haven’t begun to raise the standard of living which would give their own people a comparable quality of life. No wonder their people are pissed, and it’s a lot easier to direct that anger toward Israel and the Jews than to take responsibility for it.
I feel tremendous gratitude toward those Israelis on the front lines of ensuring that never again will Jews under threat from mounting anti-semitism or worse be without a homeland — and that threat is as real today as it ever was. It saddens me mightily to think that there won’t be real peace between Israel and all her neighbors in my lifetime. Although I sure don’t see a way forward to make peace with the Hamas terrorists, I’ll keep praying that someone will figure out how to do this because the children of Israel and of her Middle East neighbors deserve to grow up in a better neighborhood than they have now.
So When Did I Become A Zionist?
It’s often easier to see what happened when you’re looking back than when you’re in the moment. Was it when I was sitting in Independence Hall and listening to that scratched recording of the Declaration from 1948? Was it when I was struggling with my mobility issues but determined to complete the Palmach Museum’s living exhibition out of respect? When I was touching The Wall and, in doing so, establishing my own personal, physical connection to the many thousands of years of Jewish history in this place? Or seeing the stark difference between what Israelis and Diaspora Jews have done with their corner of the desert compared to what hasn’t been done for many of their Arab neighbors by their own leadership and Diaspora? Perhaps it happened when I was feeling for the first time what it’s like not to be a minority keeping my head down so as not to offend (and who among my American or European Jewish friends hasn’t been embarrassed by a too loud or too pushy member of the “tribe”)? Or maybe it was seeing those young Israelis with their automatic weapons in every cafe and plaza, each of whom has pledged their own lives to ensuring that no Jews will ever again have to live on sufferance because now we have a homeland? I really don’t know when or how the change in my thinking occurred, and it doesn’t matter. I went to Israel as a tourist, and I returned as a Zionist.
[We saw a lot more of Israel on last year’s first visit, and we made an amazing side trip to Petra in Jordan, which is a must. My travelogue notes from the road for family and friends documented the whole trip, as I try to do on every such trip. But for this blog post, I wanted to focus on my very personal reaction to visiting Israel for the first, but not the last time. We’ll be returning next year and, hopefully, many more times. Perhaps on our next trip, we’ll have time to visit some of the amazing high tech startups that Israel is producing at a rate that impresses even Silicon Valley.]
Don’t Even Think About Getting Innovation Without Disruption
[This post evolved from my Twitter reactions to a range of marketing messages and advertorials which make it sound as though their current on-premise customers, as well as the on-premise customers of other vendors, could get all the benefits of business innovation enabled by next generation HCM software without much rethinking, redesigning, and disruption. Dare I say balderdash!]
If and when you decide to migrate from your seriously old design, on-premise ERP to “the cloud,” please make sure that you get what you’re paying for. If any of the vendors proposing to subscribe you to their true or even faux SaaS products say that the new thing is non-disruptive, backward-compatible, just a migration, or similar, run for the hills. Frankly, there are only two possible interpretations of this nonsense, two alternative realities in which such statements make sense, and neither is a desirable place to bet your business or your career.
The first alternative reality is that the vendor is question has simply reincarnated much to mostly old thinking in new technology as was the case when PeopleSoft, although wonderfully new technically, was so close in domain concepts to its then mainframe competitors that it took litigation to prove that it wasn’t copied — on which point PeopleSoft won hands down — but rather just built to what were then (mid-80’s) common industry data designs, screens and processes. In this case, you’re definitely not going to get next generation HCM process or business thinking but rather the same old same old with a thin overlay of mobile delivery and enhanced analytics with (hopefully) improved costs. But the scary part of this reality is that the vendor in question may honestly not know how much change in business and HCM has taken place over the last 20+ years, or may not understand the importance of a complete rethinking of HCM with an eye on the future, and/or may honestly believe that the improvements in technology will in and of themselves drive the needed business outcomes. It’s scary but true that there may be vendors who honestly believe that non-disruption is a good thing.
The second alternative reality is a little darker although the vendor has done precisely the same thing with the software. In this case, not out of ignorance, naivete or a lack of resources, but rather out of — and this is the generous explanation — their belief that customers won’t be willing to dig in and do the heavy lifting that it takes to move from 1970 through 1990 HCM practices to ones designed for 2020 and/or that they must protect their installed base from looking at their other “cloud” options by minimizing the effort to migrate to their “cloud” applications. I do understand the enormous pressure for profits and the many other challenges that companies face when they try to reinvent themselves even as they must support current customers, but it can be done if there’s the will, early planning and effective execution. And it’s true that many customers are late adopters, not just of technology but also of major process change. I suspect late adoption/late-to-market is a big reason why the Fortune 500 company list changes SO rapidly. But HCM software vendors — for that matter all enterprise software vendors — don’t stay momentum players by being lulled into a false sense of security by there late adopter customers. Just one change in CHRO or CIO or CEO, and your previously happy on-premise customer is headed for someone else’s disruption-enabling “cloud.”
It’s really hard work, for both vendors and customers, to start over, to reconsider business processes in the face of changing times and changing technology, to design from scratch to meet tomorrow’s challenges, to clean up decades of poor data designs and coding structures, and to deliver all of this in a reasonable period of time. It’s really hard work for everyone involved to educate their organizations about the need for disruptive change, to make clear why you can’t get there from here without lightening the load of yesteryear’s thinking and doing. But only those organizations which are willing and able to reinvent themselves and their products/services frequently are going to survive and succeed. And the results of all that hard work should be disruptive, should not be backward compatible, and should be a new implementation of the enabling technology. And while you certainly don’t have to redesign every aspect of HCM at once, you can certainly use the help of a vendor which has thought through what next generation really means, not just in technology but in HCM as well, and gives you the tools you need to evolve as quickly as you can.
If you really just want something familiar but with and a more modern UX, increased processing speeds and pricing improvements, that’s fine, and there’s plenty of that to buy. But if you want to reinvent your business for the next 5, 10, even 20 years, I don’t think that’s enough. I think you need real disruption, and you need it now. As in all such matters, the consultant I used to be knows very well that it’s entirely your call how fast and with what level of innovation you move to “the cloud.” But please don’t think you’re going to get anything more than you pay for in the heavy lifting needed to achieve real innovation.
With a huge shout-out to Brian Sommer from whose wonderful blog post I “borrowed” this graphic.
[The impetus for this post was some absolute nonsense online which sort of equated SaaS to “cloud” (and faux “cloud” at that), then suggested that, while customers might save a little in the short run with SaaS, it would cost them more in the long run (here using a strictly in-house TCO cost model without much attention paid to upgrades, process modernization, etc.), and then went on to annoy the hell out of me by saying that the only one who benefits from SaaS is the vendor. This was so entirely misguided a discussion, that I couldn’t help myself from ranting online, but clearly a little more needs to be said and, perhaps, more calmly. For the record, I use a very strict definition of SaaS and will continue to do so.]
In my view, there has been entirely too much attention paid when discussing true SaaS (let alone when discussing all of the FrankenSoft — a term coined by Brian Sommer from whose post on this I “borrowed” the above graphic — and hybrid variations) to the licensing, maintenance and operational costs of on-premise, last generation business applications compared to the subscription costs of similarly titled true SaaS applications. While these costs matter, I believe that the more important discussion is around the greater breadth, availability, and pace of adoption of business-enabling innovations delivered via the architecture and business model of true SaaS.
Unless your organization is operating in the same environment as it did 20+ years ago, doing pretty much the same things within pretty much the same competitive landscape (and this is true for NO ONE), then the cost of technology-enabled innovation should be the focus of any cost comparison between on-premise or faux SaaS/”cloud” and true SaaS. The speed, ease, quality and cost of delivered innovation, as well as the ease with which that innovation is adopted and used to modernize HCM processes, are the real differentiators between the best of true SaaS and the best of on-premise — and it’s this innovation which is desperately needed by today’s organizations in order to stay relevant, let alone to succeed.
However, if your vendor has a hodge podge of bought and built architectures, object models (or even worse, old timey data models), development tools, and more moving parts than you can count, they’re at a distinct disadvantage when it comes to delivering true SaaS innovation no matter how good their intentions, how large and skilled their team, or how cleverly they reinvent themselves. Throw in a range of hybrid, on-premise, hosted and true SaaS applications, and just keeping global regulatory requirements up-to-date across this portfolio — a really big deal in HCM applications — requires substantial resources.
And even as your vendor’s team is refactoring like mad to ensure as much commonality as possible across a hodge podge portfolio, which some are doing with considerable skill and progress, every dollar spent on this type of refactoring is a dollar that’s not available to drive and deliver innovation. The more moving parts, the more it costs just to keep things moving, and that’s true no matter how able the vendor may be to deploy thousands of developers.
Now every vendor must refactor continuously at some level, but having to do so across disparate moving parts is fraught with opportunities for disconnects, quality problems, and just plain slower time, higher cost, and less robustness-to-market. But those vendors who had the luxury of:
- starting over for true SaaS, whether as new companies without an installed base or as startups within established companies (and there are some exciting skunk works in our industry);
- designing and building elegant, clean architectural and object model foundations;
- taking advantage from day one of all that’s available in technology today;
- planning for the technologies to come; and especially
- rethinking their underlying object models and end-to-end processes for the 21st century rather than deriving them from 20+ and 30+ year old HCM concepts embedded in last generation on-premise applications so as to provide as much backward compatibility as possible;
those are the vendors with a distinct advantage.
My hat’s off to my very smart colleagues pushing the innovation bow wave in front of disparate and/or heavily code-based systems with the arm of a fresh start tied behind their backs. And I admire the effective marketing that such vendors are doing to dismiss the important distinctions between true and faux SaaS, and between true cloud and traditional hosting. But in the end, I don’t think that this generation of customers is going to be fooled, for it’s a universal truth that a fool and his money is soon parted.
Objects To The Left Of Us, Objects To The Right
In May 2012, I published a blog post that covered the basics of objects and object modeling — the very basic basics. Assuming you’ve all been studying this topic since then (if you hadn’t already done so), it seemed like a good time to note that simply applying the right modeling techniques does not get you to the right HRM object models. Au contraire.
I’ve watched very smart HRM enterprise software architecture and modeling teams do their best, but it’s a rare team that doesn’t make one or more of the same errors, and they’re doozies. And while I’ve handled all of these potential errors in my HRM Object Model “Starter Kit,” which is great for licensees (please note that I no longer license this material) but not so great for everyone else, I thought I’d highlight the most challenging ones here for the benefit of those vendors — and their customers — who haven’t licensed my “Starter Kit” and even those who have a license but may not have tackled (correctly?) these specific challenges.
I should also add that, if a vendor’s applications are created/maintained via a robust, models-driven, metadata-based, effective-dated, definitional development environment, etc., it’s a lot easier to adjust the models and resulting applications over time than in a traditional, procedural logic approach to applications development — and this agility really matters. Throw in a “Blooming SaaS” architecture and fundamentally great functionality, and you’re really cookin’. Since it’s so important that the object model be fundamentally correct and complete (for the desired scope of functionality) in any software you may choose to use, and the only way to get at this, short of reviewing object diagrams (which are impenetrable for all but the fully initiated), is to use case-based (aka scenario-based) product evaluation, that’s clearly the only way to go.
Separating Job And Position
These are two fundamentally different concepts, and getting them right, along with their appropriate attributes and methods as well as relationships, goes to the heart of having an effective enterprise HRM application. Furthermore, no one should be using an HRMS, let alone any talent management applications (and you know I feel strongly that these really deserve full integration as HRMS/TM) unless both position and job are core object classes and modeled properly. Only at the lowest (and I do mean lowest) end of the market can you get away with using one or the other as a conflation of both.
Jobs are templates from which positions are created. Jobs describe broadly the nature of the work being done, in terms of what I call duties and responsibilities, as well as the KSAOCs (knowledge, skill, ability and other deployment-related characteristics, so these include surrogates like work experience and education, attitudes and behaviors, work schedule and environment preferences, etc.) and level of mastery thereof that are needed to do that work. Jobs, therefore, are the place where regulations that govern work are “hooked up” at each organization to that work. Jobs, more important than even the nature of the work they describe, can be evaluated in terms of appropriate levels and types of total compensation, thus creating eligibility for specific total compensation plans for the employees sitting in positions for which a specific job was the template. Jobs are strictly an HRM construct that let’s us group together positions doing similar work, not only for regulatory purposes, like employment equity and regulated work hours and conditions (e.g. FLSA in the USA), but also for workforce planning, labor relations, compensation management, and many, many more strategic HRM processes.
But work gets done via workers sitting in positions and carrying out the duties and responsibilities of those positions. Positions, once created from a job template must be given a work location, a work schedule, and their association with (place in) one or more work units. They may be assigned more specific duties and responsibilities, more specific KSAOCs and/or the weight and rating accorded to those KSAOCs. Positions may also be given the rules by which accounting for the costs associated with those positions will be done (i.e. when cost accounting isn’t done on a time and attendance basis), rules for any position controls (whether headcount or budgetary) that will be applied when filling those positions, and rules for establishing the fit/recruiting sources/evaluation process/etc. when filling of positions should they need filling (i.e. succession plans, sourcing rules, etc.).
So what’s the big deal here? There are a ton of organizations that think they can avoid the discipline of using positions by mushing job and position into their flawed HRMS’ job code table. You know the one. The job code table with 10,000 entries for 7,000 workers? The job code table with job descriptions like “VP — Finance,” “VP — Engineering,” and “VP — HR,” when VP is clearly the job for which there are three very different positions created. Many organizations have been dragging around these piles of job code table poop for longer than most of my readers have been sentient, and it’s clearly time to clean up this mess. But you can’t clean it up unless your HRMS handles these objects properly — and very separately. So, a job may be the template for one or more positions, but a position inherits its basic components from one and only one job.
So that I don’t violate every principle Bill Kutik has tried to teach me about reader attention spans, I’ll just do the job/position thingy here. But please stay tuned as I work through the following persistent object model errors — and let’s not even consider any vendor who’s still working with purely data models because they’re so far out of date in the art and science of software engineering that they’re probably wearing tie-dies and bell-bottoms around the office when such garb is really only appropriate when attending aging rocker or folky concerts — in subsequent posts:
- Separating Position From Worker
- Employee Status Code
- Decomposing Total Compensation Plan Into Reuseable “Legos”
- Addressing Multiple, Concurrent Worker To Position Relationships
- Balancing Total Compensation Plan With Work Environment Program
- Crafting The KSAOC Umbrella
- Community Members
- Professional Network and Networking As KSAOCs
- Separating Work Unit From Work Location
- Separating Work Unit From Legal Entity
If I get that far, and you’re still interested, I’ll keep writing on this topic. Meanwhile, if you’re a customer, starting checking your current portfolio of HRM software for the proper separation and implementation of job and position. Lots more relevant use cases for job and position can be found here and here.
[Disclosure: If you think you’ve read something very similar before, you’re quite right. And you may read an updated version in the future. I learned so much about business, absorbed it through my pores, as I worked at Bloom’s Camera (later, Bloom’s Photo Supply and then just Bloom’s, Inc.), lingered at my grandmother’s kitchen table after Friday night Shabbat meals where all the important decisions were made for that business, and was then apprenticed to all the other small businesses run by various relatives. I went on buying trips to New York for the fancy ladies wear shop run by one aunt (they used to model the dresses at high end shops), learned the uniform business from another aunt, and was taught the basics of the Borscht Belt hospitality business by a great cousin. By the time I got to my MBA program, cash flow, supply chain, human resource management and more were already baked into my world view. So, with Christmas just around the corner, I thought you might enjoy a different perspective on this holiday.]
On Christmas Eve, my Dad’s retail camera shop closed early, and we knew we’d have him with us all that next day. Really just with us, even if he were too tired for much conversation after working the very long hours of the retail Christmas season. New Year’s Day was for taking inventory, and it was all hands, even my very small hands, to the wheel. But Christmas Eve and Christmas Day were really special. Time alone with my father (of blessed memory) Jack Bloom was rare and precious. He ran a modest camera shop with his brothers Paul (who’ll be 99 on New Year’s Day 2015 and with whom I’m working on his memoir) and Herman (who published several “romantic” novels under the name Harmon Bellamy).
When I was really young, my Dad left for work before dawn and rarely got home before I was put to bed. Friday nights were usually spent having Shabbat dinner, with all my Bloom aunts/uncles/cousins and even great aunts/uncles (those without their own children), at my grandmother’s house. After dinner, Dad went off to Schul with his brothers. On Saturday mornings, we were all off to Schul, but we were orthodox so my only male first cousin, Elliot got to sit with his Dad. The store was open on Saturdays, so my Dad, in spite of the Orthodox prohibition against working on Shabbat, went from schul to work on many Saturdays, especially if they were short-handed by employee illness or vacations. Summer Sundays were for golf in the mornings and family time in the afternoons, often spent visiting family who lived far away. In those pre-turnpike (yes, before there were highways, there were turnpikes) days, the trip to Hartford, less than thirty miles away, took well over an hour. But on Christmas Eve and Christmas Day, we didn’t go visiting; we stayed home so that Dad could rest, and that meant me sitting beside him as we watched TV (once we had one) or read from the World Book Encyclopedia. My Dad was a great reader, something my sister and I have “inherited” from him.
In the run-up to Christmas, everyone worked long hours, and it was rare to see my Dad during December. My cousin Ronni (of blessed memory) and I, from about age seven, ran the strange machine in the open mezzanine above the shop floor that took addresses on metal plates and transferred them to labels for the Christmas mailing of catalogues (like the one pictured here) and calendars. Long before it was fashionable for small businesses, Bloom’s Photo Supply was into direct marketing, and we carefully collected the names and addresses of every customer and caller, all of which were entered in the perpetual address files that my Uncle Herman kept.
Sitting in the mezzanine, Ronni and I bickered over whose turn it was to load the metal plate (not fun), load the next item to be addressed (not bad), or turn the wheel (most fun) and discussed what we saw going on all around us. Excess inventory, the bane of every retailer then and now, was a major topic, along with fanciful ways of getting rid of it profitably. We also took careful note of anyone who appeared to be shoplifting, quickly reporting any irregularities with arranged signals to the salespeople on the floor, and our eyes and instincts were sharpened by experience. Even today, on the rare occasions when I’m in a store, I can’t help but notice such behaviors.
While I can never be sure, I think those conversations with Ronni must have been the origin of my now famous story about the invention of Christmas as an inventory management scheme. In that story, the wise men were retail merchants who saw in the humble birth of Mary and Joseph’s son a solution to the already age-old problem faced by retailers everywhere of how to ensure that the year ended without extraneous, highly unprofitable inventory. This is one interpretation of the Christmas story that my Christian Wallace family had never heard until they met me.
By the time we were ten, Christmas season found Ronni and me, the two youngest Bloom cousins, helping behind the counter after school and on weekends, ringing up sales, selling film and other simple products, dealing with shop-lifters rather than just watching for them from afar, recording those sales in the perpetual inventory files kept by my Uncle Herman (there never was nor ever will be again a filer like my Uncle Herman!), and generally learning the business. Everyone worked during the month before Christmas, including our mothers who were otherwise traditional homemakers, and by Christmas Eve, we were all exhausted. But the lifeblood of retail is the Christmas shopping season — always was so and still is — so our family budget for the next year was written by the ringing of those Christmas cash registers. To this day, whenever I’ve agreed to a client project or speaking engagement, I can still hear, ever so faintly, that old-fashioned cash register ka-ching.
My Dad was buried on my 50th birthday. My cousin Ronni, just four months younger than me, died in her mid-thirties. Cousin Elliot, Ronni’s older brother, and the only male Bloom cousin, took over the business from our fathers when they retired, built it into something completely non-retail but VERY successful, and sold it 15+ years ago. But if you’re ever in Springfield MA, you can still see the four story mural of long gone camera and photographic supply brands on the exposed wall of Bloom’s Photo Supply’s last retail address, on Worthington Street, just up from Main Street.
For me, sitting in my usual place at the keyboard, Christmas Eve will always be special. Years after my Dad retired and I had a business of my own, we talked daily, with me updating him on my business in response to his questions. You can’t fail to hear the ghosts of a retailer’s Christmas past even as my very non-retail business thrived. ”How’s business?” “Business is great Dad.” “Are your clients paying on time? “They sure are, Dad.” “And are their checks clearing the bank?” “Absolutely.” This Christmas Eve, I’d give every one of those checks for another Christmas with my Dad.
To all my family, friends and colleagues who celebrate the holy day of Christmas, may you and yours enjoy a wonderful sense of renewal as you celebrate the great miracle of Christ’s birth. And please pray hard, on behalf of all mankind, for more peace on earth in 2015 than we’ve had in 2014.
The Elegant Dreidel I Always Wanted
Take Your Chances, Win Some Gelt
Have you ever played the Chanukah game of spin the dreidel? Did you know that the four letters, one on each side of the dreidel, make up a phrase that translates to “a great miracle happened here.”
Chanukah celebrates the miracle of freedom, a celebration not of a military victory but rather of the miracle of G-d’s attention to the details of everyday life. Although the celebration of Christmas often falls in the same period of the Gregorian calendar as does Chanukah, and although we Jews may have added the tradition of gift-giving to Chanukah rather than listen to the cries of disappointed Jewish children, these holidays couldn’t be more different in their origins and application to modern life.
But both of them celebrate the fact that a great miracle happened here, where here is in Bethlehem for Christmas and Jerusalem for Chanukah. So, in the spirit of this miraculous season, here are the 2015 “miracles” — and I use that word intentionally because I think it would take divine intervention to achieve them — I so wish to see in our neighborhood, at the intersection of IT and HRM:
- The end of marketing speak in our industry, of calling everything you’ve got SaaS or cloud or social or integrated etc. Can you just imagine how much easier it would be for buyers and customers if there were no more “painting the roses red?”
- The end of chest beating by industry executives, of hyping their own accomplishments in hopes no one will ask too many questions, and of disrespecting the competition in loud voices and with known half-truths if not outright lies. Prospects and customers would much prefer that their vendor executives tout their customers’ accomplishments and customer satisfaction scores.
- The end of whatever atmospherics discourage so many of my young women colleagues from aspiring to be and then becoming chief architects, heads of development and CTOs. I know these problems start minutes from the womb, and our industry can’t fix all of them. However, our HR leaders can do everything in their power to level the recruitment, development and advancement playing field and to ensure that the organizational culture is welcoming to women in tech roles. As for what our IT leaders can do to help, they can make their work groups gender-neutral in every respect, from the jokes and anecdotes they tell to the respect they show for differences in styles of communication and engagement. And yes, this is of particular importance not only to me but to every employer who can’t afford to waste half of the scarce tech KSAOCs.
- The end of bad HRM object models. We know how to do this right, or at least some of us do, and it’s way past time that the mistakes of the past were relegated to that past. I can’t tell you how frustrating it is for me to review relatively new HRM software whose designers haven’t bothered to study the sins of HRM software past. Even if you have a gorgeous, easy to use, and truly efficient UX, we can’t do succession planning without the granularity of position, and we can’t do talent management without a robust, multi-dimensional understanding of KSAOCs.
- The end of bad HRM enterprise software architectures. For example, how could anyone design true HRM SaaS that doesn’t provide for cross-tenant inheritance (e.g. so that you can embed and maintain a single set of prescriptive analytics, with their content and advisory material, then inherit it across all relevant tenants — those which have signed up for this service — with appropriate modifications by geography done once and then used to modify, by geography, that decision tree of inheritance)? And how could anyone design true HRM SaaS which doesn’t express all of its business rules, from workflows to calculations, via effective-dated metadata? And, what’s even more frightening, there are folks developing HRM enterprise software who aren’t even thinking about these issues.
- The end of bad HRM enterprise software development methods. I’ve been a strong proponent of definitional, models-based development since the late 80’s. My commitment to writing less code goes back even further. So it’s little wonder that I’m stunned when I hear enterprise software execs calling attention to their thousands of programmers when they might be able to accomplish even more with fewer developers and better development methods.
I could go on, but I think you get the picture, and it would really be a miracle if we woke up on the last day of Chanukah to find that all of these wishes had come true. But even more important, although it has absolutely nothing to do with HRM or IT, I hope the miracle of good health (mental, physical, and financial) comes through for all of us. And may the lights of Chanukah be a beacon of hope for all mankind in 2015.
Payroll — You Can Laugh or You Can Cry
This post was inspired by a recent discussion among the Enterprise Irregulars. It began when one of our members called our attention to a recent story about ZenPayroll’s impressive roster of successful Silly Valley (my term for the group think or herd instinct often found in the Bay Area) entrepreneurs who had become investors. His inquiry: “Hyperbole aside, this is an impressive list of Valley investors for a space that’s admittedly crowded already with a number of “next-gen” payroll tech companies already scaling as public enterprises. Wondering what everyone thinks of this company and what, if anything, is their secret sauce?”
Now, most of the EIs spend very little time thinking about payroll software and services let alone PEOs unless they’re small businessmen themselves and have to handle this as part of running their businesses. Therefore, much of the discussion came at the question posed from an investment thesis perspective, and we all know that the entire HCM product/service space is hot, hot, hot.
But I spent many of my formative professional years designing, developing, implementing and operating payroll software, and I also ran a payroll office. More recently, I’ve spent the last few decades focused on every type of enterprise HRM technology, to include payroll, so my own comments came from a distinctly different direction. And now that I’m not providing direct consulting services and can be as blunt as I choose about such matters, I thought I’d share my comments on the amount of attention that ZenPayroll (to their credit) has been generating, about the competitive landscape in which they operate, and about the relative difficulty or ease with which a ZenPayroll becomes the next ADP.
Payroll At The Lowest End Of The Market
The lowest end of the payroll market, so those software and/or services providers (and they’re all mostly a combination since there are a lot of needed services associated with payroll, from tax filing and net pay distribution to handling garnishments and benefits administration) focused on employers with 1 to 10 or 20 or even 100 employees, is highly fragmented and includes many strictly local operators running on older technology. Some of these low end providers use homegrown software but most draw upon a few quite small providers of payroll and related software designed specifically for these smaller payroll service bureaus. By and large these specialist software vendors are not in the forefront of current software capabilities (e.g. mobile, social, analytics, consumer-driven UX, embedded intelligence, etc.) nor do their Mom and Pop owners/managers present a very Silly Valley face.
A few larger providers to the lowest end of the market have PEO business models (although some of them do everything they can not to be labeled PEO because it’s so not Silly Valley) which derive most of their income from workman’s comp administration and the premiums on various types of employer-provided insurance. TriNet is the one that gets a lot of attention because it’s been built in the Bay Area, has big name investors and leaders, and gobbled up quite a few competitors to get some real scale. They also cater to the tech startup community, which tends to have very complex compensation and benefit plan requirements. Paychex has real scale and delivery capability at the lowest end of the market, and they’ve been doing a complete technology refresh to offer a more consumer-like experience while having industrial strength behind the curtains. ADP has both PEO and non-PEO offerings at scale for the lowest end of the market, and they too are bringing a real consumer-like user experience to this market. And when ADP decides to go after a market, they can afford to price as they choose, especially with their newest technology. In case you’re wondering, several other major players at the lower end of the mid-market (so starting at a few hundred), including Ceridian/DayForce, Kronos, and Ultimate Software, don’t focus on the under 100 employee market.
Thus, the market into which ZenPayroll has inserted itself with mobile, very consumer-like software, is one which has:
- a few very capable larger players now refreshing completely their software (and, to some extent, their cultures and brands);
- a few moderately capable mid-sized players, like Paylocity, who’ve attracted significant outside investment for the first time and at a time when if you can spell SaaS and HCM you’re a candidate for such investment;
- a large number of Mom and Pop often more local operations running on either their own homegrown software or software that targets this industry from a few very small specialty software shops; and
- a few other startups which, like ZenPayroll, are bringing a very fresh look and feel to the payroll experience of small business owner/operators, particularly those who already live on their smart phones.
Payroll Starts Easy But Gets Very Tough Very Quickly
Payroll is pretty easy if you’re just building sexy-looking, modest functionality, US payroll, that automates the most common use cases and uses manual intervention to handle the very occasional variation. But it’s extremely difficult to design and build effective-dated, metadata-driven, payroll engines that can handle at scale and with minimal human intervention the full range of convoluted policies/practices/regulations/etc. that companies encounter as they grow and spread geographically.
For example, if systemic effective-dating isn’t built into the foundation, then you can’t do fully automated retroactive processing. With 10 or even 50 employees, you could handle a late-breaking set of retroactive business rule changes with brute force, so with manual calculations and lots of “zapper” transactions. But with 500 or 1,000 employees, with rules late-breaking rule changes varying by states and localities and at different times, with intervening pay rate changes, and so on, it’s not possible to do brute force retroactive processing cost-effectively and, more importantly, without huge errors. And heavily to fully automated retroactive processing, where you’re able to handle intervening rule changes along with intervening software updates, is just one example of what happens in payroll when we move from the very low end to the demands of enterprise customers.
Unless you have great software that just does it right with minimal effort or you expect your customers to do the grunt work and take the error risk unto themselves, software built for the lowest end of the market may not be able to scale up — and that’s been the case forever. There are no payroll systems today that serve equally well the 1 to 10 or even 100 employee market and the 500 to 1,000 employee and above market, and the example I’ve just given is one of the reasons. Things I must automate with great expertise and cleverness to handle complexity and scale just don’t bother me at the lowest end of the market. With roughly 18,000 regulatory jurisdictions in the USA, from taxing authorities (state, several types of local, not to mention reciprocity agreements) to judicial entities which can garnish wages, payroll software for even the low end of the middle market is expected to handle all of that, all the time, and without any slip-ups.
Another important point is that mistakes in payroll processing don’t go unnoticed, and a new and/or small player, no matter how sexy their UX nor how wealthy and prominent their backers, will get nailed with their first serious error. And the opportunities for serious errors are huge. Years ago, every tax/small business accountant did payrolls for their small customers, but many haven’t been able to keep up with the technology requirements or the complexity and risks of today’s payrolls. Banks used to do payrolling on a large scale for smaller firms, but fewer of them are doing that today for the same reasons. Presumably, the ZenPayroll guys, whom I don’t know, have tons of substantive experience and knowledge and not very little hubris. And hopefully, they have on their team one of the handful of folks who know how to design and build a modern payroll engine, i.e. an engine (not an application) which is great and durable, effective-dated, metadata-drive, scalable and low cost to operate. I haven’t yet seen any coverage of this firm which has probed deeply into their software’s architecture, their technology choices, and their operational robustness, but I’d love to read any such coverage from objective and very capable sources.
There’s a ton of low end payroll business in the USA and plenty of room for new entrants. Giving software away and making money from the sale of ancillary services or using a PEO model to derive income from insurance premiums are well-established business models in this market. But for those dollars to add up enough to be of serious interest to VCs looking for a future liquidity event, I would think you’d need a damn sight more than 1,000 separate customers with an average of 10 employees. Rather, you’d need the tens of thousands, even hundreds of thousands, of such customers now serviced by the larger players. And to keep those small business customers, I would think you’d need to offer a lot more than basic payrolling, so everything from background checking and other pre-hire services to other fundamental small market HR services like template employee “manuals,” regulator advisory services and some flavor of basic time keeping and performance management. Those fifty big name investors in ZenPayroll must have seen something, either in the competitive landscape or in the specific business model and assets of ZenPayroll, that has whetted their appetites. But it’s not obvious to me how this ever turns into the next multi-billion $$ acquisition or huge PE multiple IPO, which is probably why I won’t ever get the big bucks that VCs do.
ALL CREDIT GOES TO JOSH BERSIN FOR THIS GREAT IMAGE.
[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.