EIM Solutions Resist Commoditization with Supplementary Features

What are the standard features of an enterprise incentive management (EIM) software package?

David Kelly discusses this difficult question in an insightful recent post on his blog. Kelly points out the ambiguity of the EIM solution relative to the standardized feature set present in general ledger solutions. This is certainly true but is it necessarily a negative? I’m not sure. Of course it is definitely a bad situation if the customer is expecting one thing and does not get it or gets something undesired. Additionally, difficult system delivery issues can arise if functionality confusion causes implementation project scope growth. However, these things can and should be managed by proper pre-sale vendor product evaluation and post-sale system integration. That we don’t have 15 EIM vendor software solutions with the exact same feature set is a good thing. Sure, certain features (plan calculations, audit support, reporting) should be addressed by all packages, but supplementary features are allowing vendors to differentiate themselves and resist the move towards commoditization that has occurred with, for example, G/L packages.

A purely analytical approach might allow fairly consistent feature assignment to IT systems. However, often the realities of budgets and project planning call for a more pragmatic approach. Consider the case where a company has just the budget for a single systems project and sales incentive compensation management is the top foot-burning issue. Naturally, they would be wise to pursue an EIM solution. However, perhaps they have a secondary need of base pay management. This feature would typically be addressed by the HR system but for whatever reason, the customer’s HR system is falling short in this area. In this scenario, selection of an EIM package that addresses base pay management might make sense even if only to bridge the gap until an HR system upgrade is feasible. Even if the supplemental feature fills only a secondary need, its existence in a particular package would be very attractive to the potential customer.

In another situation, the need for insurance agents’ credential management has been identified as nearly as critical as incentive compensation for the agents; in fact the functions are often considered intertwined. This credential management function may not be considered a standard feature but for this particular customer it would be critical and a key driver in selecting the software solution.

Credential management, base/bonus management, stock option rewards management, etc. — these tweener features all part of EIM solutions from companies we work with, might not be considered standard EIM fare and some are even probably best addressed by a different type of system if they are the primary driver (buying an EIM system probably does not make sense if a company’s main need is base pay management). In any case, the existence of features in some packages considered to be outside the traditional EIM scope can be to the advantage of customers is certain situations.

Of course, customers should realize that even if a package or suite from a software vendor includes a particular secondary feature, the feature will not come for free in terms of implementation / activation costs. Additional time will be spent enabling and integrating the feature; this should be anticipated and managed. The value comes when you consider that this incremental implementation cost and the feature cost (if considered an option with an add-on charge) is still much lower than that of implementing or upgrading another separate system.

Features sets vary from one EIM solution to another and a standard set of functionality has not officially been declared. However, customers can use this to their advantage if they understand their needs and can match them to the solution that addresses them best.