Two of my long-standing HRM software architecture preferences have gone mainstream:
- True multi-tenancy, a required foundation for successful HRM SaaS products or BPO platforms; and
- Highly configurable tenants, to include the effective-dating of those configurations, full inheritance across and within tenants, and no disruption of configurations as the vendor applies new releases.
Sounds wonderful, and many HRM software vendors are on this path, as are the BPO providers wise enough to use this type of software for their delivery system platform. But even in configuration, all those available choices have to be analyzed, selected, tested and implemented, individually and in combination with other choices. And this must be done 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/change including retroactively, new executives bring new perspectives, etc.
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 the 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, we have by no means reduced the business analyst time and expertise needed to keep things running properly. And great, models-based HRM business analysts are really scarce.
This is the business case for automating as completely as possible the configuration of highly configurable, multi-tenant HRM SaaS, to include when used in BPO platforms. It’s the business case for Naomi’s interrogatory configurator, something I’ve been working on for at least ten years and which, thanks to advances in the underlying software development technologies, is getting very close to fruition.
Studying The Talmud
Interrogatory configuration is easy to explain but VERY difficult to do, at least for complex HRM software. Basically it’s a piece of software which poses questions to the client ‘s business analyst (which could be a 3rd party, including the vendor’s implementation services person), 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.
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/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.
Now imagine that the interrogatory configurator is a 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.
The bottom line. Reducing dramatically the elapsed time and cost of HRM software sales and implementation is an important enough business outcome for HRM SaaS vendors and BPO providers to justify building interrogatory configurators. Doing this requires underlying software architectures which enable configuration without miles of 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. But haven’t they been saying for years, along with their SIs, that they have the market cornered on “best practices?” If your vendor/provider isn’t working on this, won’t it be awkward for them when their competitors make the leap?
[…] Much of this list holds up well today – with the exception of BPM modeling tools. I’m no longer convinced process modeling should be a mandatory #ensw skill – perhaps it’s best seen as a specialist skill or nice to have. Experience with guided and/or interactive configuration, which many SaaS products have in some form, might be more broadly appropriate (Naomi Bloom calls this interrogatory configuration). […]
Interrogatory configuration is great to create customer specific application. Faster turnaround and customized version. The downside is more development time and specially testing cycles to make sure all combination of configuration work as expected. Also the possibility of system behaving unexpectedly grows. So HRM vendors need to be aware of that.
Mahesh, I think you may have misunderstood how this works, so perhaps I need to do a new and better post on the subject. This is no different that the wide range of expected configuration that all modern software allows and supports but rather a much more cost-effective and disciplined way of doing that configuration. So whatever testing would be done — and should be done — of such configurations should be done when the configuration process is so automated, and that’s a part of today’s implementations of the best, multi-tenant, fully effective-dated, configuration only SaaS. What’s different here is that the whole process of configuration is improved and embedded with consideration intelligence so that customers are guided through that configuration as they would be guided today by a very experienced business analyst who really knows the software, all the types of supported configurations, and what choices make the most sense under what circumstances. There’s nothing custom going on here at all.
Correct me if I’m wrong, but didn’t I see just such a configurator from Oracle, when Joel Sommers ran HCM? In short, at least five or six years ago?
[…] This post was Twitted by ronhanscome […]
Great post, Naomi. Your notion of the interrogatory configurator is highly reminiscent of conversations I had within the Product Marketing/Management team at Ceridian back in 1994-95 about the need for a tool that would be used throughout the entire sales and implementation cycle to capture customer requirements and drive accurate pricing and configuration of features/functions. We even spent some time investigating what it would take to make it happen, but abandoned the effort because of complexity, development expense and lack of supporting technology. The desire to see this tool become a reality has stayed with me since then, and I do think we’ve seen some ‘flashes of brilliance’ amongst vendor apps to date. I know that technology and tools have certainly advanced since then, but I must confess I’m still more than a little skeptical that the industry as a whole will “get there” anytime soon – accounting for all of the variables and being able to adjust/configure on the fly without screwing up current processes(not to mention the reconciliation of the data outputs/reporting over time with a constantly shifting implementation, and also how to provide proper vendor support). I believe the configurator concept is likely to evolve over time to become more robust, much like SOA was so hyped in 2002, but has taken 5+ years to truly become effective.
Ron, without something like my HRM Business Model “Starter Kit’s” foundational work, developing the needed domain expertise to feed an interrogatory configurator (assuming you’ve solved the software design issues) would be overwhelming. I worked on what’s now the implementation workbench from Oracle’s EBS HCM product suite years ago with Joel Summers, but a major challenge there was that, unless the underlying architectural is “stringable” objects or some other approach that can be configured in a fully automated fashion without having to write procedural code, you really can’t get beyond an interrogatory data collection program whose output is then used to configure.