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?