[You may also enjoy my “Firing Line with Bill Kutik” episode on this.]
There’s been a lot of discussion across the enterprise IT and financial analyst community about the long term economic viability of the SaaS business model. And the enterprise IT community continues to debate the merits of the various flavors of SaaS architectural and infrastructural models. These discussions have ranged over the:
- fundamentals of profitability in enterprise software;
- reality that many to most so-called SaaS vendors (both faux and “Blooming”) are not yet profitable;
- landrush by SaaS vendors to grab market share and to grow as rapidly as possible;
- spending by SaaS vendors of sometimes huge sums on customer acquisition against a revenue recognition requirement that expenses those acquisition costs on the front end but only allows revenue recognition over the life of the contract; and
- much more.
If the economic viability of your so-called true or faux SaaS vendors matters to you — and well it should — read on.
When you contemplate further the economics, significant future profitability appears to emerge for those vendors which are able to meet the following challenges:
- Reduce dramatically the cost of customer acquisition, from marketing to sales to contract signing;
- Reduce dramatically each customer’s time to production and, therefore, time to revenue for the vendor;
- Reduce dramatically each customer’s ongoing implementation costs and time as they take up innovation delivered by their vendor and revisit existing capabilities as their organizational needs evolve and change;
- Maintain very high customer satisfaction rates — see #3;
- Maintain very high customer retention rates, which I do believe are related to but are not the equivalent of very high customer satisfaction rates; and
- Achieve very low operational costs and error rates.
Doing all of this at the same time produces IMO the secret sauce of true SaaS economics and, in doing so, creates an enormous competitive moat for vendors who can’t achieve this. Enter Interrogatory configuration, my recommended approach to creating this moat and the really important and related benefits for both vendor and customer.
Interrogatory Configuration (yes, I know that’s lousy branding, but I’ve never claimed to be a clever marketeer) addresses the first three challenges very directly and has a positive impact on the last three. That’s why I’ve been pushing these ideas — some would say harping on them — since long before the beginning of SaaS in HR technology. Frankly, I was pushing these ideas from the late 80’s, long before they were possible to execute as they require very specific architectural foundations which, until recently, did not exist within enterprise HRM software.
So what is interrogatory configuration? Interrogatory configuration is easy to explain but VERY difficult to do, at least for complex HRM software. Basically it’s a piece of software (think TurboTax) which poses questions to the client ‘s business analyst (who could be a 3rd party, including the vendor’s implementation services person or that of a certified partner), provides a context for those questions along with the implications of selecting from among the available answers (e.g. explaining what types of organizational structures use what types of position to job relationships and why), and then, based on the selections made (and all such are of course effective-dated and subject to inheritance where appropriate), it does the configuration of the base application without manual intervention of any kind. Interestingly, Google filed a patent for a VERY limited example of this in 1997, which was awarded in 2001, in which they make clear that you can’t do this unless the underlying architecture, the software to be thus configured, is composed of objects that can be manipulated dynamically.
Highly configurable, metadata-driven, definitionally developed, true HCM SaaS is a wonderful thing. But even in configuration, all of the available choices have to be analyzed, selected, tested and implemented, individually and in combination with other choices. And this must be done with care and a deep knowledge of the downstream implications of various configurations, not only during the initial implementation but also every time business needs change, software upgrades are applied (even when applied as SaaS mostly opt-in updates), regulatory rules appear and/or change, including retroactively, new executives bring new perspectives, etc.
More Talmudic than Socratic, this question/answer dialogue continues, with each exchange doing one set of configurations while setting up the next set, until the customer has implemented fully the set of capabilities/business rules/coding structures/workflows/etc. that will be their implemented software as of the selected effective date. An interrogatory configurator is designed to work prospectively, so that you can see how a partially to fully configured application will look and behave before committing those configurations to take effect. For those configurations that are permitted to be changed retroactively, with the attendant retroactive processing once they are approved for implementation, the interrogatory configurator is also intended to work retroactively.
Without interrogatory configuration, every time those hand-done configurations must be changed, all those choices must be re-evaluated against the needed changes, and then new choices made, tested and implemented. Furthermore, the implications of each configuration change for downstream processes must be analyzed and actions taken to at least inform users of those implications. So, while we may be able to eliminate most of the programming implementation work by having great configuration tools delivered with our HRM software, without interrogatory configuration we have by no means reduced the business analyst time, effort and expertise needed to keep things running properly. And great HRM business analysts are really scarce, perhaps even more so than great HRM software developers.
Now imagine that the interrogatory configurator is an integral part of the marketing to sales cycle, allowing for a high degree of self-provisioning, at least for less complex organizations (notice I didn’t say small or quote headcounts). And even for the most complex organizations, imagine how much configuration could be done with data gleaned during the sales cycle so that a usefully configured application could become a sales cycle tool which blends seamlessly into the actual implementation once agreements are signed. To the extent that SaaS vendors proceed down this path, the whole dynamic of the sales to implementation processes, not to mention the role, staffing and economics of the systems integrators (SIs), are changed substantially, to the benefit of both the customer and the SaaS vendor.
Customer satisfaction and retention rates are driven by many factors, from having wonderful and useful product capabilities to having a very sticky user experience, and there’s a lot of room here for unique approaches by different vendors and/or for different market segments. Running a brilliant operating environment means building tools for everything from provisioning to payroll scheduling, tools which cannot be bought “off the shelf” and which are themselves complex applications. So one thing I advise all buyers to consider is how far along their proposed SaaS vendor is in having industrialized every aspect of operations, for much of which you must have the right SaaS architecture in the first place.
When I see cost comparisons between on-prem and true SaaS, it’s almost always done on a TCO basis from an IT cost perspective. But that doesn’t value not only having new functionality but also having it delivered almost continuously. It doesn’t value how much more effective vendors can be in meeting customer needs by aggregating data on feature usability and usage so as to inform their product roadmaps. And it certainly doesn’t value the ability of true SaaS vendors to aggregate benchmarking data which can then be fed right back into their interrogatory configurator, if they’ve got one, and into the analytics-rich, decision-making capabilities of their applications. So there’s a lot more here to consider than just TCO unless your business is so stagnant that you really don’t want or need agility or innovation from your systems.
There are SaaS vendors in our space that have architectures which can’t scale operationally, SaaS vendors which don’t have great operational tools, SaaS vendors whose agility is more about fixes than innovation, and so on. But I think we have some good to great SaaS vendors which will be quite profitable (or already are) because they’ve approached this new business model with the right stuff. And I would add that prospects/customers should be running for the exits from any SaaS (or so-called SaaS) vendor which isn’t well down the path of being able to meet successfully my six challenges above.
The bottom line. Reducing dramatically the elapsed time, complexity and cost of HRM software sales and implementation, not to mention ongoing configuration, is an important enough response to the six challenges above for HRM SaaS vendors and BPO providers — and creates a big enough competitive moat — to justify building interrogatory configurators. Doing this requires having the right underlying software architecture, one which enables effective-dated configuration without writing any procedural code. It also requires the product’s designers to know and be able to express the patterns of good practice in a whole range of HRM areas, from organizational designs to hiring practices, and the good practice combinations of same. And there’s an enhanced opportunity here for incorporating all manner of exogenous data, from salary surveys and hiring patterns to commentary on which organizational designs are common in specific industries — and why. If your vendors aren’t pretty far along on this, it may be too late for them to get started — or their underlying architectures just won’t support this. And if you’re a prospect for new HR technology, be sure to find out if your short list vendors are far enough down this path to ensure that they will remain viable and that your needs will be met. I’d also you’ll watch my “Firing Line with Bill Kutik” episode on this.