By Paul Devlin
Before thinking about choosing an SPM product you should deeply understand your reasons for entering the market. Without a clear conception of your goals it will be difficult to assess the relative value of the solutions being offered. Remember, of course, that organizational questions of capability, maturity, governance cannot be ignored.
Value has two components – that you got what you needed, and that what you paid is a competitive price. I mention this so as not to lose sight of the fact that, if you get things you won’t use for a very nice price, what really have you gotten?
Please note that this is not a prioritized list
· Cloud vs. On-premise
While fewer and fewer of the SPM vendors offer on-premise deployment patterns, there remain valid reasons why a company might prefer such. Among these are security, performance, and disaster recovery.
· Subscription vs. Purchase
I’m not even sure that there are purchase options available these days, but there are still companies that have financial, legal, and strategic reasons to want a product that they own. At the very least you should be able to articulate your reasons for preferring the arrangements you’re contemplating.
· Domain Boundary of the Solution
For a long time the SPM market was dominated by pure-play solutions. The products did SPM, SPM, and only SPM. These days it seems rather that the extension to related business functions, all the way from lead generation and out to monetization, rope in CPQ, do planning, quota and territory management, improve sales operations and analytics… Most vendors tout either their synergies with such functions or adjacent offerings of their own. The point here is not to be deciding what you need while shopping. Decide in advance how desirable these adjacencies are in the short and medium terms. Sales professionals will be readily forthcoming if they feel you have not formed an optimal vision.
· Ease of Use
This factor is mission-critical to adoption. Consider first who your users are. Are they captive (employees) or not (partners of some sort). Could your selection actually turn them away, dis-incent them to work with you, because of the difficulty/ugliness/lack of value in doing whatever it is you’re requiring? What benefits will they feel because they use this system?
· Ease of Implementation and Logical Maintenance
While this not as important as ‘ease of use’, it should not be disregarded. Sometimes systems with incredible capabilities have achieved those because they’ve injected profound layers of abstraction into the solution domain, layers that will require extensive integration support in order to maintain. These drive up implementation costs, risks and timelines.
· Integration Considerations and Interoperability
Inbound – are all integrations custom? What comes out of the box? How configurable is it? Will you need IT or consultants to add a new data stream? A few classes of data must enter a variable comp system – those being potentially compensable events, payee information, and system rules (including the lookup data they require). Are there specific integration configuration interfaces provided by the tool in question? For each of these streams?
Outbound – most of the questions about inbound integration capabilities pertain here, the general ones anyway. Standard outbound consumers are payroll functions, general ledger functions, regulators, and system users as described above. Does the system provide a streaming publish/subscribe method for consuming results? How does the data get to payroll? How are duplicate transmissions prevented?
Dynamic/API – Does the system provide a SOAP, REST, or other APIs? What behaviors does it expose? It that set extensible? Had one a commission calculating function within the system, could it be called from another system (Salesforce, for example) for reps to see their potential commission?
· Sufficient Role and Sharing Model Capabilities
Users of the system will fall into at least three communities – producers (of sales or service, or some behavior you’ll measure and incent), their management, and administrators. The organization of the company into various divisions and departments often becomes a community boundary. The SPM system should let you configure presentation layers (dashboards, modeling capabilities, reports) tailored by role. As much as possible, of course, these presentation layers should be device agnostic (consider mobile vis-à-vis reps). Pay attention, especially if you have a competitive vs. collaborative internal sales model, to the natural abilities of hiding or presenting rows and fields across role boundaries. Also in this layer should be a configurability of empowerment, i.e. what changes are members of group authorized to make.
· Modeling and What-iffing
This is a very high value capability. Examine both the specific and the systemic capabilities. Can the system easily show what the results of some given calculation or calculation set would be, given some arbitrary inputs? Can it easily show the difference between result sets?
· Global Organization Considerations
Examine the multi-currency and currency conversion facilities of the tool. Examine its ability to present itself in different languages.
· MDM Considerations
A little dry. It is not uncommon that some elements of a compensation system are the organizational source of record. Likewise, it can also be the case that in the compensation system some cases of multiple source systems, and the reconciliation of those source systems, must be provided. In these cases some separate interface may need be provided for that administration. In general, how, if at all, does the system ensure compliance with corporate master data rules and act as a responsible agent when it owns master data?
· Process Model
Some tools have a fixed process model along the order of ‘recognize and enhance events’, ‘attribute events to payees’, aggregate, calculate, distribute, or something along those lines. Others may have varying configurability along these lines, perhaps to aggregate and attribute at different levels at different points in the process, or to loop through previous aggregations and make attributions therefrom. Still others may have no process model per se, but rather follow the calculations embedded in whatever model you create, perhaps even executing these calculations with comparative instantaneity in a cloud-based hypercube. Be conscious of your needs.
· Persistence
Another dry subject. This goes to auditability and performance. Sometimes compensation data can be exceedingly voluminous, both on the count of the number of transactions needing recognition and of all the intermediate calculations that may want to be available for audit. Add also incremental processing, that one may have processed and paid on a transaction at time A, modified the transaction, and done it again. Does one need all versions, all intermediate states? Keeping everything can put quite a drag on performance. What persistence configurability features does the tool have?
· Workflow Capabilities
This is another very important feature. The main uses cases are internal financial rules (exceptions and approvals) and payee service (disputes, questions).
· Security Model
o External – you’ll want to understand how the system integrates with SSO schemes and whether it is capable of requiring two factor authentication
o Internal – does the tool support record level ownership? How configurable is the sharing model?
· Regulatory Conformance
This varies considerably by industry. Sarbanes-Oxley, of course, pertains across the US. In insurance there are often state by state licensing and validation rules that describe whether a rep is allowed to sell a product. The new ASC 606 rules are poised to throw major disruption into US variable compensation practices. Pay close attention to how the system accommodates the regulations pertaining to your business.
· Fundamental Variable Compensation Calculation Features
Thought we’d never get here, eh? The presumption here is that most readers are domain fluent, nonetheless we’ll mention the obvious features of: overriding settings at the transaction and individual level, having rates tables, full featured n-dimensional lookup capabilities, aggregate calculation, draw management, etc.
· Description of Time
Sounds a little general, but it can be very important. Tool should be able to describe periods, relate periods in a hierarchy, have alternative characterizations of the same moment in time (this date/time represents the fifth day of the second month for Org 1, and also the last day of the fourth bi-weekly period for Org 2, etc).
· Advanced and Edge-case Features
Here it’s about what you need. Some companies will have special needs, features not ordinarily baked into these products. These can include event-chaining, quota by customer, ability to view the past across years through the lens of the present, configurability down to the line level of general ledger outputs, predictive analytics, benchmarking – there are so many special twists. The big thing is to understand the cost/benefit you’re looking for in the feature and to specify the criteria you’ll use to qualify a possible solution.
· The Beast of Retroactivity
In an ideal world everything moves strictly forward and we never have to pretend that something was true as of a month ago, when the fact is that it wasn’t true a month ago. That’s not how business works, though, and some companies are less effective at limiting the need to evaluate new facts as if they had been true during some prior period. A host of complexities and burdens arise from this behavior; wherever possible, without a compelling business case, avoid it.
That said, there likely will be requirements in your business to sometimes need retroactive processing. Outline your cases carefully before looking at the retroactive capabilities of the product. Common cases are claw-backs, true-ups, perpetually open books, agent contracts – quite a few others. Make sure to look at this in your purchase decision.
· Support
Can be the critical difference maker. If folks aren’t paid on-time due to a system failure, heads often roll (and they only roll downhill). Understand what level of support comes with a product, what incremental subscription purchases what service, etc. Read the reviews of those with experience.
· Performance
This is primarily an issue when the compensation-driving events are great in number. At one time, for enterprise clients, this was a key differentiator. If you have a bazillion such events be sure to check out performance, get a transactions per second or credits per second or credits per second per processing agent or some meaningful metric to give you confidence in the adequacy of the tool to your needs.
· Conclusion
At the end of the day it comes down to some sort of cost and value analysis. In the final stanza you will have killed the Jabberwock. Come to my arms my beamish boy! But not exactly (no pun). For all such tools one pays something and one gets something. Something should only be counted as gotten if it will be used, otherwise it is wasted. The location of these products/services is widely spread across the cost/value spectrum. Remember that you only get so many shots at this – opportunity cost is real. To choose a product is to not choose all the others. Have the courage to own your decision matrix, to make it transparent, to recognize that changing conditions will partially invalidate all models, and to enjoy the process of driving 80% of your goals to accomplishment, maybe even with Pareto principle style.