Interrogatory Configuration And Workday’s Tech Summit 2012

“Two of my long-standing HRM software architecture preferences have gone mainstream (remember, this is 12/2009):

1. True multi-tenancy, a required foundation for successful HRM SaaS products or BPO platforms; and
2. 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.”

Thus began the introduction to my first post on interrogatory configuration, on what I saw then, and even more so now, as the key to durable success for true SaaS.  Yes, as I envision it, interrogatory configuration is an essential enabler of financial success for true SaaS vendors, of business outcomes and agility/innovation success for their customers, and of freedom for those customers (once and for all) from overly expensive and time-consuming sales cycles, implementation projects, ongoing adoption of new capabilities, and ongoing accommodation of customer business changes. 

Winding forward three years, I’m not only convinced that interrogatory configuration is that key but am heartened to see how much progress has been made by the true SaaS HRM vendor community on turning the relevant concepts and intellectual property into early stage delivery.  Therefore, among the many announcements made by Workday at their recent Technology Summit and Rising customer conference, I see their work on interrogatory configuration as having some of the most durable benefits for their customers.

Highly configurable (you already know that Workday, with release 18, will unleash the capability to extend their objects and empower these extensions with the full range of object support that every Workday object receives — see Josh Bersin’s excellent discussion), metadata-driven, definitional development is a wonderful thing.  Several of my client HRM software vendors are on this path, but Workday is still the most visible and mature true SaaS HRM vendor using these techniques — and Workday has delivered the most complete expression of them thus far.  

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 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/change including retroactively, new executives bring new perspectives, etc.

Enter interrogatory configuration, which is pretty 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 (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.  Interestingly, Google filed a patent for a VERY limited example of this in 1997, which was awarded in 2001, in which they make very 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.

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.

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 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, true HRM SaaS, to include when used in BPO platforms.  It’s the business case for my emphasis on  interrogatory configuration,  something on which I’ve been working for at least the last fifteen years and which, thanks to advances in the underlying software development technologies, is getting very close to fruition. 

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 (perhaps primed by the vendor’s CRM system?) 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 true HRM SaaS vendors proceed down this path, the whole dynamic, timeline and cost of the sales to implementation processes are improved beyond that which can be achieved otherwise.  In addition, the role, staffing and economics of the systems integrators (SIs), are changed substantially, to the benefit of both the customer and the SaaS vendor.

And that’s exactly how I read Workday’s plans in this area.  Dubbed their “Collaboration Framework,” Workday’s approach is to begin, at the earliest date of prospect interaction, to seed their Collaboration Framework with a wide range of facts about the prospect captured today via their CRM (Salesforce.com) system and then use that information to launch their interrogatory configuration.  With hundreds of business processes and reports, not to mention pre-configured security groups, landing pages and integrations, which themselves map to objects in their solution library, they envision their collaboration framework as providing the needed user experience to take prospects through a discovery process which then assembles their initial Workday tenant.  There’s a lot more to this, but at its heart, it’s about knowing which Workday objects to use where, with or without customer-specific extensions, and how the individual customer’s versions of these objects are connected to deliver the requested functionality.

The bottom line. Reducing dramatically the elapsed time and cost of HRM software sales and implementation, not to mention ongoing configuration, 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.  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 working on this, it may be  awkward for them that Workday has begun this journey in earnest.  And if you’re a true SaaS vendor in the HR technology space who’ doing something similar, I’d love to hear from you.

[The complex configuration flowchart illustration above is taken from the publicly posted http://docs.oracle.com/cd/E18727_01/doc.121/e13426/T356981T356985.htm .  This document and its associated flowchart are the detailed instructions for configuring the Oracle Treasure functions within EBS 12.1  This is precisely the type of complex configuration, where choices and downstream implications matter, that an interrogatory configurator is intended to handle during initial implementation as well as with every new release of a true SaaS product as well as with every business change which must be reflected, in an effective-dated manner, via changes to those configurations. ]